जो लोग संदर्भ बजट को गंभीरता से लेते हैं, वे बेकार Skill जमा करने वालों की तुलना में बेहतर AI सहायता अनुभव प्राप्त करते हैं।

लेखक, स्रोत: 0x9999in1, ME News

TL;DR

• वर्तमान में प्रमुख AI प्रोग्रामिंग सहायकों के स्किल/प्लगइन पारिस्थिति में, "अनियंत्रित विकास के बाद पाचन समस्या" देखी जा रही है—दोहराव, अतिरिक्त और ज़ाम्बी स्किल्स का जमावट, जो कीमती संदर्भ खिड़की संसाधनों को गंभीरता से कमजोर कर रहे हैं।
• लॉबस्टर डैड ने स्किल के लिए एक मेटा-स्किल खुला स्रोत बनाया है, जो पांच मुख्य कार्यों को कवर करता है: बजट ऑडिट, डुप्लिकेट डिटेक्शन, इनएक्टिव स्क्रीनिंग, रूट डायरेक्टरी ऑडिट, और डिस्क्रिप्शन रिडक्शन।
• कॉन्टेक्स्ट विंडो AI बड़े मॉडल के सबसे दुर्लभ संसाधनों में से एक है, और प्रत्येक अतिरिक्त स्किल की उपस्थिति आपके वास्तविक आवश्यकता के निष्कर्षण स्थान को अर्थहीन टोकन से घेर रही है।
• इस उपकरण का मूल मूल्य "एक और कौशल और जुड़ गया" नहीं है, बल्कि सभी कौशलों को एक कौशल से प्रबंधित करना है—यह बुनियादी ढांचे के स्तर का है।
• स्किल इकोसिस्टम का अव्यवस्था एक व्यक्तिगत घटना नहीं है, बल्कि एक संरचनात्मक समस्या है। ऑडिट तंत्र के बिना प्लगइन प्रणाली अंततः एन्ट्रोपी में वृद्धि की ओर बढ़ेगी।
• Open source means the community can iterate on this, which could be the starting point for Skill governance standardization.

सबसे पहले वर्तमान स्थिति: आपका Skill रिपॉजिटरी, संभवतः एक कचरा भंडार बन चुका है

यह बात कठोर है। लेकिन अपने AI सहायक कॉन्फ़िगरेशन को खोलें, और देखें कि आपने कितने स्किल इंस्टॉल किए हैं, और सोचें कि पिछली बार आपने कौन से कुछ ही इस्तेमाल किए थे।

उत्तर अधिकांशतः चुप्पी ला देगा।

2025 के दूसरे छमाही से, Cursor, Windsurf, Codex, Claude Code जैसे AI प्रोग्रामिंग टूल्स एक साथ "कौशल सैन्य प्रतिस्पर्धा" में प्रवेश करते हैं। समुदाय योगदानकर्ता बेपनाह मात्रा में योगदान दे रहे हैं, आधिकारिक अंतर्निहित पुस्तकालय लगातार बढ़ रहे हैं, और व्यक्तिगत कॉन्फ़िगरेशन बार-बार जुड़ रहे हैं।

What's the result?

एक आम भारी उपयोगकर्ता, जिसके स्किल की संख्या आसानी से 50 से अधिक होती है। जिनमें से दैनिक रूप से ट्रिगर होने वाले, संभवतः 10 से कम होते हैं। शेष 40, शांति से वहाँ पड़े रहते हैं, प्रत्येक संवाद शुरू होने पर संदर्भ में लोड होते हैं, टोकन बजट का शांति से उपयोग करते हैं, और फिर—कुछ भी नहीं करते।

यह बर्बादी नहीं है। यह अपराध है।

ऐसा क्यों? क्योंकि कॉन्टेक्स्ट विंडो असीमित नहीं है। भले ही 2026 तक, प्रमुख मॉडल की प्रभावी कॉन्टेक्स्ट लंबाई 128K से 200K टोकन के बीच होगी, जो बहुत अधिक लगता है, है ना? लेकिन गिनिए: सिस्टम प्रॉम्प्ट, डायलॉग हिस्ट्री, कोड स्निपेट्स, फाइल कंटेंट, टूल परिभाषाएँ, स्किल विवरण... "सोचने" के लिए वास्तविक रूप से छोड़ा गया स्थान, आपकी कल्पना से कहीं कम है।

एक अनावश्यक कौशल का विवरण 200 टोकन घेरता है, 50 टोकन 10,000 टोकन होते हैं। दस हजार टोकन, मॉडल को 400 पंक्तियों कोड पढ़ने के लिए पर्याप्त हैं।

यह केवल एक सैद्धांतिक अनुमान नहीं है। यह हर दिन हो रहा है।

क्यों कोई नहीं रोक रहा? क्योंकि "जोड़ना" "घटाने" से एक लाख गुना आसान है

मनुष्यों में एक गहराई से जड़े हुए मनोवैज्ञानिक विकार होता है: जोड़ने की प्रवृत्ति (Addition Bias)।

हम समस्याओं का समाधान करने के लिए स्वाभाविक रूप से "कुछ जोड़ने" की कोशिश करते हैं, न कि "कुछ हटाने" की। 2021 में प्रकाशित एक अध्ययन ने स्पष्ट रूप से दर्शाया कि मनुष्य अपनी वस्तुओं में सुधार करते समय "घटाव समाधान" को व्यवस्थित रूप से नज़रअंदाज़ कर देते हैं, भले ही घटाव अधिक प्रभावी हो।

Skill इकोसिस्टम ने इस विचलन का पूर्ण पुनर्निर्माण किया है।

समुदाय योगदानकर्ता ने एक नया स्किल लिखा और प्रकाशित किया। उपयोगकर्ता को लगा "शायद उपयोगी होगा", इसलिए उन्होंने इसे इंस्टॉल किया। ऑफिशियल को लगा "फ़ंक्शन कवरेज व्यापक है", इसलिए इसे अंतर्निहित कर दिया गया।

कौन हटाएगा? कौन ऑडिट करेगा? कौन कहेगा "यह स्किल उससे दोहरा रहा है, एक को हटा दो"?

कोई नहीं।

क्योंकि कोई प्रोत्साहन नहीं है। एक नया स्किल बनाएं, जिससे स्टार मिलें, समुदाय द्वारा मान्यता मिले, और रिज्यूमे में शामिल किया जा सके। एक पुराने स्किल को साफ करना? कुछ भी नहीं मिलता।

यह एक संरचनात्मक संकट है। यह तकनीकी समस्या नहीं है, यह प्रेरणा संरचना की समस्या है।

जब तक किसी ने फैसला नहीं किया: मुझे प्रोत्साहन की फिक्र नहीं, मैं यह काम करूंगा।

Lobster Father strikes: Uses one Skill to govern all Skills

लॉबस्टर फादर कौन हैं? अगर आप AI प्रोग्रामिंग टूल समुदाय में हैं, तो आप इस आईडी से परिचित होंगे। कोडेक और क्लॉड इकोसिस्टम में लंबे समय से सक्रिय गहन खिलाड़ी, जो व्यवस्थित सोच और इंजीनियरिंग की सफाई के लिए जाने जाते हैं। "लॉबस्टर फादर" यह नाम समुदाय की मान्यता को दर्शाता है—जिसे "फादर" का खिताब दिया जाता है, वह किसी विशिष्ट क्षेत्र में वह व्यक्ति होता है जिसके बिना आगे बढ़ना असंभव है।

इस बार उसके द्वारा ओपन सोर्स किया गया चीज़ मूल रूप से एक मेटा-स्किल है।

मेटास्किल क्या है? यह "कौशल के प्रबंधन का कौशल" है। यह आपको कोड लिखने में मदद नहीं करता, एपीआई नहीं ठीक करता, दस्तावेज़ नहीं बनाता। यह केवल एक ही काम करता है: आपके मौजूदा सभी कौशलों का एक व्यापक, मापनीय और कार्यान्वयन योग्य निदान करना।

पांच मुख्य क्षमताएँ, प्रत्येक को अलग-अलग समझाया गया है।

यह सबसे कठोरतम है।

यह बहुत सीधा काम करता है: प्रत्येक Skill द्वारा उपयोग किए जाने वाले संदर्भ टोकन स्थान की गणना करता है, प्रत्येक का कुल बजट का प्रतिशत निकालता है, और फिर अनुकूलन सुझाव देता है।

क्योंकि अधिकांश उपयोगकर्ताओं को "स्किल ने वास्तव में कितने संसाधन खपत किए" के बारे में पूरी तरह से अहसास नहीं है।

आप सोचते हैं कि एक स्किल इंस्टॉल करना केवल एक अतिरिक्त फीचर जोड़ना है। वास्तव में, प्रत्येक स्किल का विवरण टेक्स्ट, पैरामीटर परिभाषा, उदाहरण कोड, और ट्रिगर नियम सभी को सिस्टम प्रॉम्प्ट में शामिल किया जाना चाहिए। मॉडल प्रत्येक निष्कर्ष निकालने पर, इन सामग्रियों को "पढ़ने" के बाद ही यह तय करता है कि क्या इसका उपयोग करना है।

यह ऐसा है जैसे आप एक पहाड़ चढ़ने के बैग में 50 उपकरण ले जा रहे हों। आप सोचते हैं कि "ले जाने से कोई नुकसान नहीं", लेकिन हर एक किलोग्राम बढ़ने से आपकी शारीरिक ऊर्जा कम होती जाती है। जब आपको वास्तव में तेजी से आगे बढ़ने की जरूरत होती है, तो आपके पास कोई शक्ति नहीं बची होती।

बजट ऑडिट का काम है कि आपके बैग को खोलकर आपको बताए: "यह स्विस आर्मी नाइफ 3 किलो वजन करती है लेकिन आपने कभी इसका उपयोग नहीं किया, इसे फेंक दें।"

इस फीचर द्वारा हल किए जा रहे समस्याएँ, आपकी कल्पना से अधिक गंभीर हो सकती हैं।

इसकी स्कैनिंग चार स्तरों तक फैली हुई है:

• Codex का अंतर्निहित पुस्तकालय
• प्लगइन कैश
• code repository
• Personal Skills Root

Scan across levels for skills with the same name, similar descriptions, and overlapping functions, and flag redundant items.

क्यों दोहराव होता है? कारण कई हैं।

ऑफिशियल रूप से एक "कोड फॉर्मेटिंग" स्किल अंतर्निहित है, आपको इसके बारे में पता नहीं था, और आपने समुदाय से एक लगभग समान कार्यवाही वाला स्किल इंस्टॉल कर लिया। दो स्किल, एक ही काम कर रहे हैं, दो बजट का उपयोग कर रहे हैं।

या और अधिक गुप्त रूप से: आपने छह महीने पहले JSON पार्सिंग के लिए एक कस्टम स्किल लिखा था, बाद में आधिकारिक अपडेट में, बिल्ट-इन लाइब्रेरी में एक बेहतर विकल्प जोड़ दिया गया। आपका पुराना संस्करण अभी भी मौजूद है, और किसी ने आपको हटाने के बारे में नहीं बताया है।

डुप्लिकेट डिटेक्शन सिर्फ नाम पर ही नहीं देखता। अलग-अलग नाम होने पर भी, अगर विवरण अत्यधिक समान है, तो उसे भी चिह्नित कर दिया जाएगा। यही वास्तविक तकनीकी क्षमता है—इसे सेमेंटिक समानता की तुलना करनी होती है, सिर्फ स्ट्रिंग मैचिंग नहीं।

इतिहास के लॉग के आधार पर, लंबे समय से अनुपयोगित "ज़ॉम्बी स्किल्स" की पहचान करें।

यह तर्क स्पष्ट है: यदि कोई स्किल पिछले 30 दिनों, 60 दिनों, 90 दिनों में कभी ट्रिगर नहीं हुआ है, तो यह अधिक संभावना है कि दो स्थितियों में से एक है—या तो आपका वर्कफ्लो इसकी आवश्यकता नहीं करता, या इसके ट्रिगर की शर्तें इतनी खराब डिज़ाइन की गई हैं कि मॉडल कभी इसे चुनता ही नहीं है।

चाहे कोई भी स्थिति हो, निष्कर्ष एक ही है: यह बजट को बेकार खर्च कर रहा है।

इस फ़ंक्शन से एक "साफ़ करने के उम्मीदवार सूची" उत्पन्न होती है। ध्यान दें, यह "उम्मीदवार" है, सीधे हटाए जाने के लिए नहीं। अंतिम निर्णय उपयोगकर्ता के हाथ में है। यह डिज़ाइन बहुत संयमित और बुद्धिमान है—यह जानता है कि इसकी सीमाएँ कहाँ हैं।

कुछ कौशल वास्तव में कम आवृत्ति वाले लेकिन महत्वपूर्ण होते हैं। उदाहरण के लिए, "डेटाबेस माइग्रेशन सहायता", आप शायद तीन महीने में एक बार ही इस्तेमाल करें, लेकिन जब आप इसका उपयोग करते हैं तो यह बचाव करता है। इसलिए, स्क्रीनिंग परिणाम संदर्भ हैं, न कि फैसला।

यह फीचर "ऑपरेशन्स" के अधिक करीब है, लेकिन यह बहुत उपयोगी है।

यह सभी स्किल के स्रोत निर्देशिकाओं की गणना करता है, सक्षम/अक्षम स्थिति को चिह्नित करता है, और लोडिंग श्रृंखला को स्पष्ट करता है।

इसकी आवश्यकता क्यों है? क्योंकि स्किल के स्रोत विविध हैं। कुछ वैश्विक कॉन्फ़िगरेशन से, कुछ प्रोजेक्ट-स्तरीय कॉन्फ़िगरेशन से, कुछ प्लगइन द्वारा स्वचालित इंजेक्शन से, और कुछ उपयोगकर्ता द्वारा मैनुअल रूप से बनाए गए हैं।

जब स्किल की संख्या कम होती है, तो आपको पता होता है। जब संख्या कई दर्जन तक बढ़ जाती है, तो आपको समझ नहीं आता कि "यह स्किल कहाँ से आया?", "क्या मैं इसे सुरक्षित रूप से हटा सकता हूँ?", "हटाने से क्या अन्य चीजों पर प्रभाव पड़ेगा?"

Root directory audit is like giving you a map. It tells you where each Skill lives, who loaded it, and whether it's alive or dead.

With this map, you can perform the surgery safely.

अंतिम सुविधा, जो सबसे "छोटी" लगती है, वास्तव में बहुत अधिक लीवरेज रखती है।

यह जो करता है: अत्यधिक लंबे विवरण वाले स्किल की पहचान करता है और संक्षिप्तीकरण के सुझाव प्रदान करता है।

क्यों विवरण की लंबाई इतनी महत्वपूर्ण है? पिछले बात पर वापस जाएं: स्किल विवरण को सिस्टम प्रॉम्प्ट में शामिल किया जाता है। प्रत्येक शब्द एक टोकन है। यदि एक स्किल का विवरण 200 टोकन से 80 टोकन तक संकुचित किया जा सकता है, तो स्किल की संख्या के साथ बचत की गई जगह का कुल योग बहुत अधिक होता है।

कई समुदाय योगदानकर्ताओं द्वारा दिए गए स्किल के विवरण प्रबंधन सारांश की तरह लिखे गए हैं—पृष्ठभूमि, प्रेरणा, उपयुक्त परिदृश्य, ध्यान देने योग्य बातें, उदाहरण इनपुट और आउटपुट, बहुत सारा। लेखक का अच्छा इरादा है, लेकिन इंजीनियरिंग के दृष्टिकोण से, यह अतिरंजित डिज़ाइन है।

मॉडल को आवश्यक विवरण: सटीक, अद्वितीय, भेदयोग्य। इतने शब्दों में समझाएं कि यह कौशल क्या करता है और इसे कब बुलाएं—अतिरिक्त प्रत्येक शब्द संदर्भ बजट का व्यर्थ खर्च है।

इस फीचर को संक्षिप्त करना, मूल रूप से "प्रॉम्प्ट इंजीनियरिंग का उल्टा अनुकूलन" है—बेहतर प्रॉम्प्ट लिखने के बजाय, मौजूदा प्रॉम्प्ट को छोटा किया जाता है, जबकि जानकारी की मात्रा अपरिवर्तित रहती है।

वह क्या है जिसमें सच्चा मूल्य है? फीचर नहीं, बल्कि सोच का तरीका है।

पाँच फीचर्स पूरी तरह से अलग-अलग किए गए हैं। प्रत्येक को अलग से देखें तो लगता है कि वे कोई "भव्य परिवर्तन" नहीं हैं। लेकिन जब वे एक साथ जुड़ते हैं, तो वे एक सोच के दृष्टिकोण के परिवर्तन को दर्शाते हैं:

From "creating more Skill" to "governing existing Skill".

इस बात की कीमत कोड की मात्रा या एल्गोरिदम की जटिलता में नहीं, बल्कि इसमें है कि अंततः किसी ने इस समस्या को "प्रथम श्रेणी का नागरिक" मानना शुरू कर दिया है।

पिछले दो वर्षों में, AI उपकरण पारिस्थितिकी का ध्यान केवल "जोड़ने" पर केंद्रित था। अधिक मॉडल, अधिक कार्य, अधिक प्लगइन, अधिक स्किल। तेज़ी से दौड़ना, जोरदार दौड़ना, कोई पीछे मुड़कर नहीं देख रहा था।

लेकिन कोई भी इंजीनियरिंग का अनुभव रखने वाला जानता है: जब तक एक प्रणाली की जटिलता एक निश्चित सीमा तक नहीं पहुँच जाती, बिना संबंधित शासन तंत्र के, यह ढह जाती है।

नहीं संभव। निश्चित रूप से।

सॉफ्टवेयर इंजीनियरिंग में "टेक्निकल डेब्ट" नाम की एक अवधारणा है। प्रत्येक अस्थायी समाधान, प्रत्येक "अभी इसी तरह चलते हैं", और प्रत्येक अप्रयुक्त अतिरिक्त कोड ऋण ले रहा है। जितना अधिक ऋण लिया जाता है, उतना ही ब्याज बढ़ता है, जब तक कि एक दिन आप नहीं पाते कि आपकी सभी ऊर्जा ऋण चुकाने में लग गई है, और नए काम करने के लिए कोई शक्ति शेष नहीं रही है।

स्किल इकोसिस्टम की तकनीकी ऋण, अब इसे स्वीकार करने का समय है।

लॉबस्टर फादर टूल, मूल रूप से एक ऋण ऑडिटर है। यह आपके ऋण चुकाने में मदद नहीं करता, लेकिन यह आपको बताता है: आप कितना ऋण लेने के लिए देनदार हैं, ऋण कहाँ है, और किन्हें प्राथमिकता दी जानी चाहिए।

यह "एक उपयोगी स्किल और लिखा गया" से कहीं अधिक मूल्यवान है।

खुले स्रोत का अर्थ: व्यक्तिगत उपकरण से समुदाय मानक तक

लॉबस्टर फादर ने ओपन सोर्स करने का फैसला किया, जो खुद में एक बड़ी बात है।

वह इस उपकरण को एक भुगतान आधारित प्लगइन के रूप में बना सकता था। बाजार की मांग स्पष्ट है, दर्द के बिंदु वास्तविक हैं, और भुगतान करने वाले उपयोगकर्ता कम नहीं होंगे। लेकिन उसने ओपन सोर्स का चयन किया।

क्यों?

मुझे लगता है कि दो स्तरों का विचार है।

पहला स्तर: इस उपकरण को वास्तविक मूल्य प्राप्त करने के लिए, समुदाय द्वारा संयुक्त रूप से विकास की आवश्यकता होती है। विभिन्न AI प्लेटफॉर्मों के स्किल लोडिंग मैकेनिज़म, लॉग फॉर्मेट और डायरेक्टरी स्ट्रक्चर अलग-अलग होते हैं। एक व्यक्ति इसे अनुकूलित नहीं कर सकता, लेकिन सौ योगदानकर्ता कर सकते हैं।

दूसरा स्तर: वह केवल एक उपकरण ही नहीं, बल्कि एक मानक को भी आगे बढ़ाना चाह सकता है। स्किल गवर्नेंस कैसे किया जाए? ऑडिट के आयाम क्या हैं? बजट आवंटन के सर्वोत्तम अभ्यास क्या हैं? इन प्रश्नों के उत्तर बनाने के लिए समुदाय की सहमति की आवश्यकता होती है।

Open source is the best way to form consensus.

सॉफ्टवेयर इंजीनियरिंग के इतिहास को देखें, ESLint जावास्क्रिप्ट कोड स्टाइल के लिए, Black पायथन फॉर्मेटिंग के लिए, Prettier फ्रंटएंड कोड स्टाइल के लिए—ये उपकरण खुले स्रोत के कारण समुदाय के नियम निर्धारण में भागीदारी के कारण वास्तविक मानक बन गए हैं।

क्रैब फादर का यह मेटा-स्किल, क्या स्किल गवर्नेंस के लिए ESLint बन सकता है?

अभी निर्णय लेना जल्दी है। लेकिन दिशा सही है।

एक गहरा प्रश्न: क्या स्किल सिस्टम को फिर से डिज़ाइन किया जाना चाहिए?

ऑडिट टूल "स्टॉक समस्या" को हल करते हैं। लेकिन यदि हम दृष्टिकोण को एक स्तर ऊपर उठाते हैं, तो हम एक अधिक मौलिक समस्या को देखते हैं:

क्यों स्किल नियंत्रण से बाहर हो जाता है?

उत्तर है: वर्तमान स्किल प्रणाली में जीवन चक्र प्रबंधन की कमी है।

एक स्किल बनाए जाने के बाद, यह हमेशा के लिए मौजूद रहता है। कोई अवधि समाप्ति नहीं है, कोई संस्करण अप्रचलित होना नहीं है, कोई सक्रियता में कमी नहीं है। यह एक ऐसी प्रक्रिया की तरह है जो कभी मरती नहीं है, संसाधनों का उपयोग करती रहती है, जब तक कि कोई इसे मैन्युअली नहीं बंद कर देता।

ऑपरेटिंग सिस्टम के प्रक्रिया प्रबंधन की तुलना करें: बनाया जाता है, शेड्यूल किया जाता है, सोया जाता है, समाप्त किया जाता है। जीवन चक्र पूर्ण बंद लूप है।

अब पैकेज मैनेजर के निर्भरता प्रबंधन की तुलना करें:npm auditसुरक्षा विरोधाभासों की जांच करें, npm outdatedपुराने निर्भरताओं की जांच करें, npm pruneअनावश्यक पैकेज हटाएं। गवर्नेंस टूल इकोसिस्टम का हिस्सा हैं।

स्किल सिस्टम कहाँ है? बनाएँ → उपयोग करें → …… खत्म। बीच में कई चरण गायब हैं।

लॉबस्टर फादर का टूल, मूल रूप से, सिस्टम डिज़ाइन की कमी को बाहरी टूल्स से पूरा करता है। यह उपयोगी है, लेकिन यह एक तथ्य को भी उजागर करता है: AI टूल प्लेटफॉर्म में Skill गवर्नेंस के लिए बुनियादी ढांचा अभी शुरुआती चरण में है।

यह आलोचना नहीं है। यह विकास के चरण का अनिवार्य हिस्सा है। 2024 से 2025 तक, प्लेटफॉर्म का प्राथमिक लक्ष्य "पारिस्थिति को चलाना" है, प्रशासन को बाद में संबोधित किया जा सकता है। लेकिन 2026 के मध्य तक, पारिस्थिति पहले से ही चल रही है। अब समय है कि हम पिछड़े हुए पाठ्यक्रम को पूरा करें।

अंत में लिखें

मूल प्रश्न पर वापसी: आपके AI सहायक में कितने स्किल सक्रिय हैं?

अगर आप इसका जवाब नहीं दे सकते, तो आपको एक शारीरिक परीक्षण कराने की आवश्यकता है।

लॉबस्टर फादर ने टूल दिया। मुफ्त। ओपन सोर्स। पांच आयाम, सम्पूर्ण कवरेज।

यह आपका मामला है।

लेकिन एक बात मैं निश्चित हूँ: जो लोग संदर्भ बजट को गंभीरता से लेते हैं, वे बेकार Skill जमा करने वालों की तुलना में बेहतर AI-सहायता अनुभव प्राप्त करेंगे।

क्योंकि AI सब कुछ नहीं है। इसका ध्यान सीमित है, इसकी याददाश्त सीमित है, और इसके तर्क के संसाधन सीमित हैं। जितना अधिक सटीक और स्वच्छ जानकारी आप इसे देते हैं, उतना ही बेहतर आउटपुट यह आपको वापस देता है।

यह अंधविश्वास नहीं है। यह सूचना सिद्धांत है।

शैनन ने 1948 में हमें बताया था: चैनल क्षमता सीमित होती है, जितना अधिक शोर होगा, उतनी ही कम प्रभावी सूचना संचरण दर होगी।

आपकी स्किल सूची में जो ज़ोंबी स्किल हैं, वे शोर हैं।

Eliminate them.

रेफरेंस

1. एडम्स, जी. एस., कॉनवर्स, बी. ए., हेल्स, ए. एच., और क्लॉट्ज, एल. ई. (2021). लोग प्रणालीगत रूप से घटाव परिवर्तनों को नज़रअंदाज़ करते हैं।Nature, 592(7853), 258–261.
2. शैनन, सी. ई. (1948). ए मैथमैटिकल थ्योरी ऑफ कम्युनिकेशन। बेल सिस्टम टेक्निकल जर्नल, 27(3), 379–423।
3. OpenAI. (2024). GPT-4 Turbo कंटेक्स्ट विंडो और टोकन सीमाएँ दस्तावेज। https://platform.openai.com/docs/models
4. Anthropic. (2025). Claude मॉडल कार्ड: कॉन्टेक्स्ट विंडो उपयोग और सिस्टम प्रॉम्प्ट ओवरहेड। https://docs.anthropic.com/en/docs/about-claude/models
5. कर्सर टीम। (2025)। नियम और कौशल: कस्टम निर्देशों को कॉन्टेक्स्ट में कैसे लोड किया जाता है। कर्सर डॉक्यूमेंटेशन।
6. npm दस्तावेजीकरण। (2025)। npm-audit, npm-prune: पैकेज जीवनचक्र का प्रबंधन। https://docs.npmjs.com/cli
7. लॉबस्टर फादर। (2026)। स्किल हेल्थ चेक मेटा-स्किल [ओपन सोर्स प्रोजेक्ट]। GitHub रिपॉजिटरी।
8. Sculley, D., et al. (2015). Hidden Technical Debt in Machine Learning Systems. Advances in Neural Information Processing Systems (NeurIPS), 28.