आमंत्रित करें और कमाएँ

आमंत्रण पुरस्कार कैसे काम करते हैं

अपना आमंत्रण लिंक साझा करें। मित्र इसके माध्यम से पंजीकरण करके टॉप-अप करता है तो उसके बाद के टॉप-अप पर आपको दिखाया गया पुरस्कार मिलेगा।

Claude Code में Skills प्रबंधन: संदर्भ बजट को बढ़ाए बिना आवश्यक क्षमताएं कैसे बनाए रखें

Claude Code स्किल्स का व्यावहारिक ऑडिट: हमेशा चालू रहने वाले नियमों और आवश्यकतानुसार ट्रिगर होने वाले वर्कफ़्लो को अलग करने की चरणबद्ध मार्गदर्शिका।

विषय-सूची

Claude Code का नियमित इस्तेमाल करने पर खास स्क्रिप्ट, फ़ॉर्मैटिंग नियम, टाइप जाँच और फ़्रेमवर्क टेम्प्लेट बढ़ते जाते हैं। हर साधन को स्थायी निर्देश बनाने से पहला काम शुरू होने से पहले ही संदर्भ बजट खर्च होता है। यहाँ हम स्किल्स की सूची जाँचेंगे, स्थायी नियमों को ज़रूरत पर चलने वाली प्रक्रियाओं से अलग करेंगे और देखेंगे कि मॉडल सही स्किल खोज पाता है या नहीं।

सत्र शुरू होने पर क्या लोड होता है

सामान्य सत्र में on वाली स्किल का नाम और description मॉडल को दिखता है। name-only में केवल नाम रहता है। user-invocable-only या disable-model-invocation: true विवरण को मॉडल से छिपाते हैं; off पूरी स्किल को छिपाता है। SKILL.md का पूरा भाग कॉल होने पर लोड होता है और उसी सत्र में रहता है। सहायक फ़ाइलें ज़रूरत पर पढ़ी जाती हैं और स्क्रिप्ट टूल की तरह चलती हैं। यह व्यवहार आधिकारिक Skills दस्तावेज़ में बताया गया है।

खर्च को तीन हिस्सों में देखें: सूची में नाम, विवरण और ट्रिगर; कॉल के बाद पढ़े जाने वाले निर्देश; और ज़रूरत पर इस्तेमाल होने वाले संदर्भ व स्क्रिप्ट। बड़ा API मैनुअल या कोड बनाने के विस्तृत नियम सीधे description या वैश्विक CLAUDE.md में रखने से काम शुरू होने से पहले संदर्भ भर जाता है।

अपनी BetterToken API Key से परीक्षण करते समय Dashboard में मॉडल, समय, स्थिति और input, output तथा cache Token के आधार पर कॉल मिलाएँ। इससे वास्तविक API अनुरोध की जाँच होती है, लेकिन कौन-सी स्थानीय स्किल ने संदर्भ लिया, यह नहीं पता चलता। यह /context का विकल्प नहीं है। मौजूदा कनेक्शन सेटिंग BetterToken Docs में देखें।

स्किल्स बहुत बढ़ जाएँ तो /skill-doctor से शुरू करें

जब सूची को हाथ से समझना कठिन हो, स्थानीय Claude Code सत्र में /skill-doctor चलाएँ। यह संदर्भ खर्च और कॉल की आवृत्ति दिखाता है तथा लोड हो चुकी लेकिन इस्तेमाल न हुई स्किल्स पहचानने में मदद करता है। इंटरैक्टिव रिपोर्ट /plugin प्रबंधक के Stats टैब में खुलती है। इसमें अंतर्निहित और एंटरप्राइज़ स्किल्स शामिल नहीं हैं। रिपोर्ट का विवरण देखें।

  1. नियमित इस्तेमाल वाला प्रोजेक्ट चुनें और सूची को उसके सामान्य कामों से मिलाएँ। कॉल का रिकॉर्ड न होना, बेकार होने का प्रमाण नहीं है। रिकवरी की प्रक्रिया कई महीनों में एक बार काम आ सकती है।
  2. कम इस्तेमाल होने वाली व्यक्तिगत या प्रोजेक्ट स्किल को /skills में user-invocable-only करें; मेनू में इसका नाम user-only है। उस वातावरण में अब ज़रूरत न हो तो off चुन सकते हैं। प्लगइन की स्किल्स /plugin से संभालें।
  3. नया सत्र खोलकर /context की तुलना करें। एक सामान्य काम और बचाई गई कम उपयोग वाली स्किल की सीधी कॉल जाँचें। संदर्भ घटाना तभी उपयोगी है जब ज़रूरी काम अब भी हो सके।

इस कमांड का उल्लेख v2.1.261 रिलीज़ नोट में है, जबकि मौजूदा दस्तावेज़ न्यूनतम संस्करण v2.1.252 बताते हैं। claude --version से संस्करण देखें। उपलब्धता feature flags प्राप्त होने पर भी निर्भर करती है। Remote Control में रिपोर्ट उपलब्ध नहीं है; इसे उस मशीन के टर्मिनल में चलाएँ जहाँ सत्र चल रहा है। कमांड न मिले तो नीचे दी गई हाथ से जाँच जारी रखें।

स्थान और उपयोग के आधार पर सूची बनाएँ

प्रोजेक्ट की .claude/skills/ और व्यक्तिगत ~/.claude/skills/ सूची देखें। किसी उपनिर्देशिका की स्किल उसके अंदर की फ़ाइल पहली बार पढ़ने या बदलने के बाद उपलब्ध हो सकती है; सभी स्किल्स शुरुआत में नहीं दिखतीं। प्लगइन स्किल का अपना namespace होता है और उसे skillOverrides नियंत्रित नहीं करता। सिंक की गई स्किल्स का पता लगाने का तरीका भी स्थानीय सत्र, Cowork और cloud में अलग है। इसलिए हर इस्तेमाल किए जाने वाले वातावरण में फ़ाइल सूची को /skills से मिलाएँ।

उपयोगकाम के उदाहरणकहाँ रखें
रोज़कोड शैली, टेस्ट, git statusछोटे CLAUDE.md नियम या बुनियादी स्किल
काम के अनुसारDB माइग्रेशन, OpenAPI बनाना, रिलीज़ जाँचस्पष्ट और सीमित description वाली स्किल
कम या वास्तु-संबंधी कामशुरुआती सुरक्षा ऑडिट, नई सेवा तैनात करनाuser-only स्किल, सीधी कमांड और scripts

सुरक्षा, रिकवरी और रिलीज़ प्रक्रिया कम इस्तेमाल होने पर भी सीधे कॉल की जा सकनी चाहिए। वास्तविक काम जाँचने के बाद ही उसे बंद करने का निर्णय लें।

हर समय संदर्भ में न रहने वाले नियम कहाँ रखें

मान लें कि जनरेट किए गए दस्तावेज़ को मूल फ़ाइलों और जनरेटर से अपडेट करना है। अलग-अलग ज़रूरतों के लिए अलग साधन चुनें।

ज़रूरतसाधनक्या जाँचें
हर काम में अपडेट का तरीका याद दिलानाछोटा CLAUDE.md नियमनया सत्र फ़ाइल पढ़ता है
दस्तावेज़ अपडेट करते समय प्रक्रिया चलानाअलग स्किलसीधी कॉल मूल फ़ाइल और जनरेटर कमांड खोजती है
चलने से पहले खास लेखन रोकनाPreToolUse Hookटूल को मना किया जाता है और फ़ाइल नहीं बदलती
परिणाम की स्वतंत्र जाँचज़रूरी टूल वाला Subagentरिपोर्ट में सत्यापन है और अधिकार काम तक सीमित हैं
बाहरी सिस्टम से डेटा लेनाMCP कनेक्शनसही सर्वर पर एक अनुमति-प्राप्त अनुरोध संभव है

CLAUDE.md और स्किल मॉडल को निर्देश देते हैं। “generated को संपादित न करें” लिखना, लेखन रुकने का प्रमाण नहीं है। Hook का इवेंट, matcher और वास्तविक अस्वीकृति जाँचें। Write पर रोक Bash से लिखने को नहीं रोकती। अलग संदर्भ वाला Subagent भी अपने-आप read-only नहीं होता। ये अंतर साधनों के परिचय और Hooks संदर्भ में दिए गए हैं।

एक ही प्रक्रिया पाँच जगह कॉपी न करें। CLAUDE.md में छोटा नियम और स्किल का संदर्भ रखें। उदाहरण के लिए CLAUDE.md नियम, Stop Hook से पूर्णता की जाँच और MCP या कमांड का चयन देखें। Stop Hook काम खत्म होने की जाँच करता है; वह लिखने से पहले वाले PreToolUse का विकल्प नहीं है।

छोटा प्रवेश बिंदु और सहायक संसाधन रखें

1. YAML frontmatter साफ़ करें

description में काम का उद्देश्य और स्पष्ट ट्रिगर लिखें। इस सेटिंग उदाहरण में Prisma स्कीमा बदलने पर माइग्रेशन की जाँच और उसे लागू करने का उपयोग बताया गया है।

---
name: db-migrator
description: >-
  डेटाबेस स्कीमा बदलने पर Prisma माइग्रेशन की जाँच और उसे लागू करने के लिए इस्तेमाल करें।
---

विवरण में लंबे कोड उदाहरण न रखें। विस्तृत तालिकाएँ और उदाहरण references/ में ले जाएँ।

2. दोहराई जाने वाली जाँच स्क्रिप्ट को दें

मॉडल से हर बार लंबे निर्देशों के आधार पर जटिल पार्सिंग या जाँच कमांड बनाने के बजाय स्किल की scripts/ निर्देशिका में shell या Python स्क्रिप्ट रखें। SKILL.md में रास्ता और निर्णय के मानदंड रहें।

<!-- SKILL.md के अंदर -->
स्कीमा की अखंडता जाँचने के लिए यह चलाएँ:
```bash
python3 "${CLAUDE_SKILL_DIR}/scripts/validate_schema.py" --strict
```

स्क्रिप्ट खुद टेस्ट की गई हो और समान इनपुट पर चलाई जाए, तो परिणाम दोहराना आसान होता है। Token बचाने के लिए ज़रूरी सुरक्षा जाँच, लिंटर या टाइप जाँच बंद न करें।

पहचान और कॉल की चार चरणों में जाँच

1. चार जाँच अलग रखें

test -f YAML सत्यापन नहीं है। अलग-अलग देखें कि SKILL.md मौजूद है; frontmatter YAML पार्सर से पढ़ा जाता है और description खाली नहीं है; references/, examples/ और scripts/ के रास्ते स्किल की निर्देशिका से सही खुलते हैं; और सुरक्षित इनपुट पर स्क्रिप्ट अपेक्षित exit code देती है। python3 से चलने वाली Python फ़ाइल के लिए executable bit अनिवार्य नहीं है।

2. दिखने की स्थिति और सीधी कॉल देखें

नए सत्र में /skills खोलकर नाम, स्रोत और कॉल का मोड देखें। फिर सुरक्षित परीक्षण काम में /db-migrator को सीधे कॉल करें। इससे स्किल न मिलने की समस्या और उसके निर्देशों की समस्या अलग होती हैं।

3. अपने-आप ट्रिगर होना जाँचें

एक और नया सत्र खोलें और स्किल का नाम लिए बिना कहें: “डेटाबेस में उपयोगकर्ता मॉडल अपडेट करके माइग्रेशन की जाँच करनी है।” मॉडल को description से काम पहचानना चाहिए, db-migrator के निर्देश लोड करने चाहिए और तैयार जाँच स्क्रिप्ट चलाने का सुझाव देना चाहिए।

4. सूची और शुरुआती संदर्भ मापें

इस्तेमाल न हुई स्किल्स के लिए ऊपर वाला /skill-doctor चलाएँ। /doctor से सूची का खर्च और बड़े योगदानकर्ता देखें, फिर /context की Skills पंक्ति का आकार लिख लें। विवरण छोटा करने या कम उपयोग वाली स्किल को user-only करने जैसा एक बदलाव करें और नए सत्र में तुलना दोहराएँ।

केवल Token न देखें। सही अनुरोध पर सही स्किल चलनी चाहिए, असंबंधित अनुरोध पर नहीं चलनी चाहिए, और काम की जाँच सफल होनी चाहिए। always-on, auto-triggered, user-only, name-only और off को अलग पहचानें। सुरक्षा या रिकवरी स्किल को केवल कम उपयोग के कारण न हटाएँ।

अपना LLM वर्कफ़्लो बेहतर बनाना चाहते हैं?

एक API से मॉडल जोड़ें, कुंजियाँ प्रबंधित करें और AI खर्च नियंत्रित करें।

मुफ़्त शुरू करें