Claude Code skills: skills कैसे काम करते हैं, SKILL.md क्या है और agent उन्हें कब लोड करता है

Claude Code में skills क्या हैं

Skill एक फ़ोल्डर है, जिसमें SKILL.md फ़ाइल होती है। उसमें किसी खास प्रकार के काम का निर्देश लिखा होता है: प्रोजेक्ट को deploy कैसे करना है, review कैसे करना है, release कैसे निकालना है। Agent सत्र की शुरुआत से जानता है कि skill मौजूद है, पर उसे पूरा तभी पढ़ता है जब काम सचमुच उसकी माँग करता है।

Claude Code skills उस समस्या को हल करती हैं जो CLAUDE.md लंबे समय तक लिखने वालों को परेशान करती है: निर्देशों की फ़ाइल फैलती जाती है। 80 पंक्तियों की deploy प्रक्रिया हफ़्ते में एक बार चाहिए, पर वह हर सत्र के संदर्भ में जगह घेरती है, यहाँ तक कि README में एक वर्तनी सुधारते समय भी। Skill ऐसी प्रक्रियाओं को स्थायी संदर्भ से निकालकर ज़रूरत पड़ने पर जोड़ती है।

Skill किन चीज़ों से बनती है

सबसे छोटी skill एक फ़ोल्डर और एक फ़ाइल है। प्रोजेक्ट की skills रिपॉज़िटरी में रहती हैं, और निजी skills उपयोगकर्ता की home डायरेक्टरी में:

.claude/skills/deploy/SKILL.md      # प्रोजेक्ट की skill, git के ज़रिए पूरी टीम के लिए
~/.claude/skills/review/SKILL.md    # निजी skill, सभी प्रोजेक्ट्स में उपलब्ध

SKILL.md के साथ सहायक फ़ाइलें भी रखी जा सकती हैं: टेम्पलेट, scripts, संदर्भ-सामग्री। Agent इन्हें तभी खोलेगा जब मुख्य टेक्स्ट उनका हवाला दे और उनकी ज़रूरत पड़े:

.claude/skills/deploy/
├── SKILL.md           # मुख्य निर्देश
├── checklist.md       # विस्तृत चेकलिस्ट, लिंक से पढ़ी जाती है
└── rollback.sh        # rollback की script

Frontmatter: name और description

फ़ाइल की शुरुआत --- पंक्तियों के बीच YAML ब्लॉक से होती है। बाकी सभी फ़ील्ड से ज़्यादा महत्वपूर्ण दो हैं: name — skill का छोटा नाम, और description — बताता है कि skill क्या करती है और उसे कब लगाना है।

---
name: deploy
description: होस्टिंग पर FTP से साइट का deploy। जब बदलाव सर्वर पर भेजने हों, सर्वर से अंतर जाँचना हो या deploy वापस लेना हो, तब उपयोग करें।
---

# Deploy

1. पहले ट्रायल रन: `./deploy.sh -n`.
2. फ़ाइलों की सूची जाँचें: उसमें सीक्रेट्स और परीक्षण scripts नहीं होने चाहिए।
3. भेजें: `./deploy.sh`.
4. बदले हुए पेज खोलें और सुनिश्चित करें कि वे 200 लौटाते हैं।

Rollback — इसी फ़ोल्डर की rollback.sh देखें।

Frontmatter के नीचे साधारण Markdown होता है: चरण, कमांड, सीमाएँ, पास की फ़ाइलों के लिंक। इसे उसी तरह लिखें जैसे किसी नए सहकर्मी के लिए लिखते, जो यह काम पहली बार कर रहा है।

Agent skill कब लोड करता है

सत्र की शुरुआत में संदर्भ में केवल हर उपलब्ध skill का नाम और विवरण जाता है। हर skill के लिए यह कुछ पंक्तियाँ हैं, इसलिए दर्जनों skills रखना संभव है। जब उपयोगकर्ता का अनुरोध या काम का मौजूदा चरण विवरण से मेल खाता है, तब agent skill को चुनता है, और तभी SKILL.md का पूरा टेक्स्ट संदर्भ में जाता है।

इससे एक व्यावहारिक नियम निकलता है: skill विवरण के आधार पर चलती है। Agent skill का मुख्य हिस्सा तब तक नहीं देखता जब तक उसने उसे खोलने का फ़ैसला न किया हो। अगर description में लिखा है «सहायक skill», तो agent नहीं समझेगा कि उसकी ज़रूरत कब है। अगर लिखा है «होस्टिंग पर deploy; जब बदलाव सर्वर पर भेजने हों या deploy वापस लेना हो तब उपयोग करें», तो वह समझ जाएगा।

स्वचालित चयन के अलावा skill को नाम से सीधे भी बुलाया जा सकता है, स्लैश के साथ, जैसे /deploy। यह तब उपयोगी है जब आप जानते हैं कि किस प्रक्रिया की ज़रूरत है और agent के अनुरोध को विवरण से मिलाने पर निर्भर नहीं रहना चाहते।

Description ऐसा लिखें कि skill लगे

• क्या करती है — एक वाक्य में, क्रिया से: «साइट का deploy», «commit से पहले बदलावों का review»।
• कब उपयोग करें — वे शब्द लिखें जिनमें उपयोगकर्ता असल में यह काम माँगता है: «सर्वर पर भेजो», «upload करो», «वापस लो»।
• कब उपयोग न करें, अगर skill किसी पड़ोसी skill जैसी लगती है: «बॉट के deploy के लिए नहीं, केवल साइट के लिए»।
• «उपयोगी skill» और «काम में मदद करती है» जैसे सामान्य शब्दों से बचें — उनमें कोई संकेत नहीं होता।

Progressive disclosure

Skills progressive disclosure के सिद्धांत पर बनी हैं: जानकारी परतों में दी जाती है, और हर अगली परत तभी लोड होती है जब उसकी ज़रूरत हो।

यह वही विचार है जो निर्देश-फ़ाइल में लंबी सूची की जगह राउटर रखने का है: एक छोटा नक्शा हमेशा सामने रहता है, विवरण लिंक से मिलते हैं। फ़र्क यह है कि skill इस तरह की लोडिंग को सामान्य तंत्र बना देती है, न कि इस उम्मीद पर छोड़ती है कि agent खुद सही दस्तावेज़ खोल लेगा। एक और फ़ायदा: तीसरी परत की script agent पूरी तरह संदर्भ में लाए बिना चला सकता है।

Skills, CLAUDE.md और slash-कमांड: अंतर क्या है

तीनों तरीके agent को निर्देश देते हैं, पर अलग समय पर और संदर्भ पर अलग लागत के साथ।

चुनने का व्यावहारिक नियम सरल है। जो निर्देश लगभग हर काम में चाहिए, उसकी जगह CLAUDE.md है। जो निर्देश किसी प्रकार के कामों में चाहिए, वह skill है। अगर आप हर बार एक ही लंबा अनुरोध खुद टाइप करते हैं, तो वह slash-कमांड या हाथ से बुलाई जाने वाली skill का उम्मीदवार है।

सख्त रोक को skill में न डालें। हो सकता है skill लोड ही न हो, जबकि «सीक्रेट्स कभी commit न करें» नियम हमेशा लागू रहना चाहिए। ऐसे अटल नियम CLAUDE.md में रहते हैं और जहाँ संभव हो, तंत्र से समर्थित होते हैं: hooks, access rights, CI की जाँच।

Claude Code के लिए skill कैसे बनाएँ: चरण दर चरण

1. दोहराई जाने वाली प्रक्रिया खोजें। अच्छा संकेत: आप agent को एक ही बात तीन बार समझा चुके हैं, या CLAUDE.md में कोई खंड है जो दस में से एक काम में चाहिए।
2. फ़ोल्डर बनाएँ .claude/skills/<नाम>/ और उसके भीतर SKILL.md।
3. Frontmatter लिखें name और description के साथ, जहाँ साफ़ लिखा हो कि skill कब लगानी है।
4. चरण लिखें ठोस कमांड और तैयारी के मानदंडों के साथ: क्या जाँचना है, किस परिणाम को सफलता मानना है।
5. लंबी सामग्री अलग फ़ाइलों में रखें और मुख्य टेक्स्ट से उनका लिंक दें।
6. CLAUDE.md से दोहराव हटाएँ, केवल एक संकेत-पंक्ति रखकर: «Deploy — skill deploy»।
7. जाँचें: नए सत्र में काम अपने शब्दों में माँगें, skill का नाम लिए बिना, और देखें कि agent उसे उठाता है या नहीं। न उठाए तो विवरण दोबारा लिखें।

Skills के उदाहरण

Deploy की skill

यह सबसे स्वाभाविक उम्मीदवार है: प्रक्रिया दुर्लभ, लंबी और खतरनाक है, और गलती महँगी पड़ती है। Skill में चरणों का क्रम (पहले ट्रायल रन, फिर भेजना), क्या नहीं भेजना, परिणाम कैसे जाँचना और वापस कैसे लौटना, यह दर्ज रहता है। हर कोड-संपादन पर agent को यह याद रखने की ज़रूरत नहीं पड़ती — केवल तब जब बात सर्वर की आती है।

Review की skill

---
name: review
description: commit से पहले मौजूदा बदलावों का review। जब diff जाँचना हो, बदलावों में गलतियाँ ढूँढनी हों या बदलावों को commit के लिए तैयार करना हो, तब उपयोग करें।
---

# बदलावों का review

1. diff लें: `git diff` और `git diff --staged`.
2. हर बदली फ़ाइल के लिए जाँचें:
   - उपयोगकर्ता का इनपुट आउटपुट में escape होता है;
   - SQL queries parameterized हैं;
   - कोई debug आउटपुट या अस्थायी फ़ाइलें नहीं हैं।
3. प्रोजेक्ट के टेस्ट और linter चलाएँ (कमांड CLAUDE.md में हैं)।
4. रिपोर्ट: फ़ाइल और पंक्ति के साथ समस्याओं की सूची, गंभीर से छोटी तक.
   समस्या न हो तो यही लिखें, बिना गढ़े हुए टिप्पणियों के।

ऐसी skill «देख लो, सब ठीक है या नहीं» को हर बार एक ही बिंदुओं के साथ दोहराई जा सकने वाली जाँच में बदल देती है।

सत्र समाप्त करने की skill

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

आम गलतियाँ

• धुंधला विवरण। Skill मौजूद है, पर agent उसे नहीं बुलाता। ठोस trigger-शब्दों के साथ description दोबारा लिखें।
• Skill जो पूरा उपन्यास है। पुराने पूरे 400 पंक्तियों के खंड को SKILL.md में डाल दिया। संदर्भ का फूलना बस बाद में लौट आया। मुख्य टेक्स्ट छोटा रखें, विवरण अलग फ़ाइलों में।
• CLAUDE.md से दोहराव। एक ही प्रक्रिया दो जगह लिखी है और समय के साथ अलग हो जाती है। सच्चा स्रोत एक ही होना चाहिए।
• एक-दूसरे से टकराती skills। मिलते-जुलते विवरण वाली दो skills: agent बेतरतीब चुनता है। «उपयोग करें / न करें» से दोनों को अलग करें।
• पुराने कमांड। Script का नाम बदला, पर skill पुराने नाम का हवाला देती है। Skill प्रोजेक्ट के कोड का हिस्सा है: प्रक्रिया बदलने वाले उसी commit में उसे भी बदलें।

कब खंड को skill में ले जाने का समय है

समय-समय पर CLAUDE.md देखें और हर खंड के लिए पूछें: सामान्य कामों के कितने हिस्से में इसकी सचमुच ज़रूरत होती है? अगर लगभग हमेशा — तो वह अपनी जगह पर है। अगर दस में से एक काम में — तो वह skill का उम्मीदवार है।

दूसरा संकेत है लंबाई। जो खंड एक स्क्रीन में नहीं समाता, वह लगभग निश्चित रूप से नियम नहीं, प्रक्रिया लिखता है। प्रक्रियाएँ तब पढ़ना आसान है जब काम हो रहा हो, न कि पूरे सत्र में पृष्ठभूमि में रखी जाएँ।

तीसरा संकेत है बार-बार दोहराई जाने वाली व्याख्या। अगर आप agent को एक ही काम पर बार-बार वही स्पष्टीकरण दे रहे हैं, तो उसे एक बार skill में लिख दें। एक हफ़्ते बाद देखें कि हाथ से सुधार कम हुए या नहीं: यही जाँच है कि skill काम कर रही है।

निष्कर्ष

Claude Code skills प्रक्रियाओं को प्रोजेक्ट के साथ रखने का तरीका हैं, जिसके लिए हर सत्र में संदर्भ का खर्च नहीं देना पड़ता। Skill का विवरण हमेशा दिखता है, मुख्य टेक्स्ट ज़रूरत पड़ने पर लोड होता है, और सहायक फ़ाइलें उसके भी बाद आती हैं। CLAUDE.md में प्रोजेक्ट का नक्शा और सख्त नियम रहते हैं, और skills में deploy, review, release और अन्य विशेष प्रकार के काम। निर्देश-फ़ाइलों की संरचना और संदर्भ के progressive disclosure को हम harness engineering के कोर्स में व्यावहारिक रूप से समझाते हैं।