अपनी खुद की Agent Skill कैसे लिखें: स्टेप-बाय-स्टेप गाइड

अपनी खुद की एजेंट स्किल को एक वास्तविक विफलता से तैयार करें

अपनी खुद की एजेंट स्किल लिखने का सबसे अच्छा तरीका इसे एक वास्तविक विफलता से तैयार करना है। ऐसा कार्य खोजें जिसे आपके कोडिंग एजेंट ने दो बार गलत किया हो, उन सुधारों को लिखें जिन्हें आपने दोनों बार टाइप किया था, और उस सुधार को एक SKILL.md फाइल के रूप में सहेजें जिसे एजेंट स्वयं लोड कर सके। इसके बाद की हर चीज केवल मैकेनिक्स है: फाइल का लेआउट, और वह एक लाइन जो यह तय करती है कि स्किल कभी ट्रिगर होगी या नहीं।

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

दो बार गलत किए गए कार्य से शुरुआत करें

एक बार होना संयोग है। दो बार होना एक पैटर्न है, और पैटर्न एक फाइल बनाने लायक होता है।

यहाँ एक ऐसी विफलता है जो वास्तविक सर्वर पर बार-बार होती है। आप एजेंट से Nginx में reverse proxy block जोड़ने के लिए कहते हैं। यह /etc/nginx/conf.d/app.conf को एडिट करता है, फिर sudo systemctl restart nginx चलाता है। एडिट में एक टाइपो (typo) है, इसलिए Nginx स्टार्ट होने से मना कर देता है, और जब तक आप इसे ठीक नहीं करते, साइट डाउन रहती है:

nginx: [emerg] unknown directive "proxy_pas" in /etc/nginx/conf.d/app.conf:12
Job for nginx.service failed because the control process exited with error code.

आप चैट में इसे ठीक करते हैं। सर्विस को छूने से पहले sudo nginx -t के साथ कॉन्फ़िगरेशन का परीक्षण करें, फिर restart के बजाय reload के साथ इसे लागू करें। एक सप्ताह बाद, किसी अन्य कार्य पर, वही गलती। वह दूसरी बार संकेत है।

जब विफलता आपके सामने हो, तो दो चीजें लिख लें: आपके द्वारा टाइप किया गया अनुरोध, और आपके द्वारा दिया गया सुधार, उन्हीं शब्दों में जिनका आपने उपयोग किया था। वे दो पंक्तियाँ कौशल (skill) बन जाती हैं। अनुरोध आपको बताता है कि ट्रिगर को किससे मेल खाना चाहिए। सुधार पूरी सामग्री है।

Anthropic का अपना ऑथरिंग मार्गदर्शन इसे सबसे पहले रखता है। एजेंट को बिना किसी कौशल के प्रतिनिधि कार्यों (representative tasks) पर चलाएं, रिकॉर्ड करें कि वह कहाँ विफल होता है, फिर वे न्यूनतम निर्देश लिखें जो उन विफलताओं को ठीक करते हैं। विफलताएं ही विनिर्देश (specification) हैं, इसलिए ऐसा कौशल जिसे आप किसी विफलता से वापस ट्रेस नहीं कर सकते, आमतौर पर ऐसा कौशल है जिसकी किसी को आवश्यकता नहीं थी।

उसी आसवन (distillation) के एक कार्यशील उदाहरण के लिए, Ponytail एक बार-बार होने वाली विफलता को, एक ऐसा एजेंट जो आपके द्वारा मांगे गए से कहीं अधिक फिर से लिखता है, एक कौशल में बदल देता है आप अपना खुद का लिखने से पहले इसे शुरू से अंत तक पढ़ सकते हैं।

Skill की संरचना

एक skill एक ऐसी directory है जिसमें एक अनिवार्य file होती है।

.claude/skills/nginx-config-changes/
├── SKILL.md
├── reference/
│   └── proxy-headers.md
└── scripts/
    └── check-and-reload.sh

SKILL.md एक frontmatter block के साथ खुलती है, जिसमें --- markers के बीच YAML (वही configuration format जिसका उपयोग Docker Compose files करती हैं) में कुछ settings लिखी होती हैं, जिसके बाद markdown में निर्देश होते हैं। ऊपर दी गई विफलता के लिए पूरी skill यहाँ दी गई है।

---
name: nginx-config-changes
description: Tests and reloads nginx safely after a config edit. Use when editing files under /etc/nginx, adding a server block or a reverse proxy, or changing a TLS certificate path.
---

## Rules

Run `sudo nginx -t` after every edit under `/etc/nginx`. Do not touch the service until it prints `test is successful`.

Apply the change with `sudo systemctl reload nginx`. Never use `restart`. A reload keeps the running workers serving traffic until the new config parses, so a broken config leaves the site up. A restart stops nginx first, so a broken config takes the site down.

If `nginx -t` fails, fix the file and test again. Never reload a config that failed the test.

For the proxy header defaults this project expects, see [reference/proxy-headers.md](reference/proxy-headers.md).

वह file बीस लाइनों से कम की है और यह एक पूर्ण skill है। इसके भाग इस प्रकार हैं:

• name: अधिकतम 64 characters, केवल lowercase अक्षर, अंक और hyphens, और इसमें claude या anthropic शब्द नहीं होने चाहिए। व्यक्तिगत या project skill में यह केवल display label है। आप जो command type करते हैं वह directory के नाम से आती है, इसलिए यह /nginx-config-changes पर प्रतिक्रिया देती है।
• description: skill क्या करती है और इसका उपयोग कब करना है, अधिकतम 1,024 characters। यह line वास्तविक काम करती है, और अगला भाग केवल इसी के बारे में है।
• Body: निर्देश, जो केवल तब load होते हैं जब skill वास्तव में चलती है।
• reference/: अतिरिक्त files जिन्हें agent मांग पर पढ़ता है। उन्हें SKILL.md से link करें और links को एक स्तर गहरा रखें, क्योंकि एक referenced file से link की गई file अक्सर केवल आंशिक रूप से ही पढ़ी जाती है।
• scripts/: वे files जिन्हें agent पढ़ता नहीं बल्कि execute करता है। केवल उनका output ही context की लागत बढ़ाता है, इसलिए 300 लाइन की script सस्ती पड़ती है।

किसी skill को पूरा layout तब मिलता है, जब वह जिस व्यवहार को ठीक करती है वह इतना जड़ हो कि इसके लिए विस्तृत संरचना आवश्यक हो; और unlazy skill उस स्थान का उपयोग Depth Tree, gates files के समूह और PLAN.md contract के लिए करती है, ताकि agent यह घोषित न कर सके कि काम पूरा हो गया है, जबकि काम की पूरी शाखाएँ अभी छुई तक न गई हों।

आप directory कहाँ रखते हैं, यह तय करता है कि skill किसे मिलेगी।

• repository में .claude/skills/<name>/SKILL.md: केवल इस project के लिए, और यह हर उस व्यक्ति के पास जाती है जो repo को clone करता है।
• ~/.claude/skills/<name>/SKILL.md: आपकी machine पर हर project के लिए, और किसी और के लिए नहीं।
• <plugin>/skills/<name>/SKILL.md: plugin के अंदर ship की गई, जहाँ भी वह plugin enabled हो, वहाँ उपलब्ध।

mkdir -p .claude/skills/nginx-config-changes के साथ एक बनाएँ और file लिखें। Claude Code इन directories पर नज़र रखता है, इसलिए मौजूदा skill को edit करने पर वह चल रहे session के भीतर प्रभावी हो जाता है। एक top-level skills directory बनाना जो session शुरू होने पर मौजूद नहीं थी, उसके लिए restart की आवश्यकता होती है, क्योंकि session शुरू होने पर निगरानी के लिए कुछ भी नहीं था।

Description field फाइल की सबसे महत्वपूर्ण पंक्ति है

Startup के समय agent हर उपलब्ध skill के name और description को अपने context में load करता है। यह body को load नहीं करता है। जब आपका request आता है, तो वह एक पंक्ति ही यह तय करने का एकमात्र आधार होती है कि क्या यह skill प्रासंगिक है, इसलिए अस्पष्ट description के पीछे की बेहतरीन body कभी पढ़ी ही नहीं जाती।

Description को third person में लिखें। "Tests and reloads nginx safely" सही है। "I can help you with nginx" सही नहीं है, क्योंकि यह text system prompt में डाला जाता है, जहाँ first person का अर्थ यह निकलता है कि model खुद के बारे में बात कर रहा है।

इसमें दो चीजें शामिल करें: skill क्या करती है, और वह किस स्थिति में लागू होती है। महत्वपूर्ण use case को पहले रखें, क्योंकि Claude Code listing entry को 1,536 characters पर काट देता है। अतिरिक्त trigger phrases और उदाहरण requests के लिए एक वैकल्पिक when_to_use field है, और इसे उसी सीमा के अंतर्गत description के नीचे जोड़ दिया जाता है।

फिर उन शब्दों का उपयोग करें जिन्हें आप वास्तव में type करेंगे। description: Helps with nginx किसी से match नहीं करता, क्योंकि कोई भी "helps with" type नहीं करता है। ऊपर दिया गया version /etc/nginx, server block, reverse proxy और TLS (transport layer security) certificate path का नाम लेता है, जो लगभग उस हर request की शब्दावली है जिसे इसे trigger करना चाहिए।

यहाँ description के लिए एक test है। उस एक पंक्ति को किसी ऐसे व्यक्ति को दें जिसने body कभी नहीं देखी है, साथ ही वह request भी दें जिसे आप type करने वाले हैं, और उनसे पूछें कि क्या यह skill लागू होती है। यदि वे नहीं बता सकते, तो model भी नहीं बता पाएगा।

बॉडी को छोटा रखें, क्योंकि यह संदर्भ में बनी रहती है

जब कोई skill invoke की जाती है, तो उसका रेंडर किया गया कंटेंट एक संदेश के रूप में बातचीत में शामिल हो जाता है और सत्र के शेष भाग के लिए वहीं रहता है। Claude Code बाद के टर्न में फ़ाइल को दोबारा नहीं पढ़ता है। आपके द्वारा लिखी गई प्रत्येक पंक्ति एक ऐसी लागत है जिसे आप पूरे सत्र के लिए चुकाते हैं, न कि केवल एक उत्तर के लिए।

Anthropic का सुझाव है कि SKILL.md को 500 पंक्तियों से कम रखें और विवरण को अलग फ़ाइलों में ले जाएँ। कॉम्पैक्शन (compaction) दिखाता है कि यह संख्या मनमानी क्यों नहीं है। जब संदर्भ को खाली करने के लिए बातचीत का सारांश (summarize) बनाया जाता है, तो Claude Code प्रत्येक skill के सबसे हालिया इनवोकेशन को फिर से जोड़ता है, प्रत्येक के केवल पहले 5,000 tokens रखता है, और सबसे हाल ही में invoke की गई skill से शुरू करके 25,000 tokens का संयुक्त बजट भरता है। एक लंबी skill बीच में ही कट जाती है। कई लंबी skills एक-दूसरे को पूरी तरह से बाहर धकेल देती हैं।

इसलिए केवल वही लिखें जो मॉडल पहले से नहीं जानता है। वह जानता है कि nginx क्या है और reverse proxy क्या करता है। वह restart के ऊपर reload के बारे में आपके हाउस रूल को नहीं जानता है, और वह नियम ही एकमात्र कारण है कि यह फ़ाइल मौजूद है।

यदि skill एजेंट को एक बंडल की गई स्क्रिप्ट चलाने के लिए कहती है, तो पथ (path) का नाम ${CLAUDE_SKILL_DIR} के साथ रखें ताकि यह वहीं resolve हो जहाँ skill इंस्टॉल की गई है, और उसी कमांड को पहले से approve करें ताकि रन किसी अनुमति प्रॉम्प्ट (permission prompt) पर न रुके।

---
name: nginx-config-changes
description: Tests and reloads nginx safely after a config edit. Use when editing files under /etc/nginx, adding a server block or a reverse proxy, or changing a TLS certificate path.
allowed-tools: Bash(${CLAUDE_SKILL_DIR}/scripts/check-and-reload.sh *)
---

अनुदान (grant) उस टर्न को कवर करता है जिसने skill को invoke किया था और आपके द्वारा अपना अगला संदेश भेजने पर यह साफ़ हो जाता है, इसलिए यह चुपचाप स्थायी अनुमति नहीं बनता है।

यह कैसे सिद्ध करें कि skill सक्रिय हो रही है

किसी skill के लोड होने को देखने से केवल यह पता चलता है कि agent ने उसे ढूँढ लिया है। इससे यह पता नहीं चलता कि उत्तर बदल गया है या नहीं। दोनों की जाँच करें, और एक नए session में जाँच करें, क्योंकि जिस session में आपने skill लिखी है, उसमें वह सब कुछ मौजूद है जो आपने उसे लिखते समय कहा था। वह बचा हुआ context फ़ाइल में मौजूद कमियों को छिपा देता है।

1. project में claude के साथ एक नया session शुरू करें।
2. अनुरोध को उसी तरह टाइप करें जैसे आप किसी सामान्य कार्य दिवस पर करते हैं, अपने शब्दों में, बिना skill का नाम लिए।
3. invocation पर नज़र रखें। यदि skill सक्रिय नहीं होती है, तो description को ठीक करें। body अभी समस्या नहीं है।
4. नियंत्रण के रूप में /nginx-config-changes के साथ इसे मैन्युअल रूप से invoke करें। मैन्युअल रूप से invoke करने पर सही व्यवहार और अनुरोध द्वारा invoke करने पर गलत व्यवहार यह पुष्टि करता है कि समस्या instruction की नहीं, बल्कि trigger की है।
5. skill को बंद करके वही अनुरोध चलाएँ और दोनों उत्तरों की तुलना करें। /skills menu में, skill को highlight करें, उसकी स्थिति को off पर बदलने के लिए Space दबाएँ, फिर save करने के लिए Enter दबाएँ। यह .claude/settings.local.json में एक skillOverrides प्रविष्टि लिखता है, और काम पूरा होने पर Space को फिर से दबाने से यह वापस on पर आ जाता है।
6. कुछ ऐसे अनुरोध लिखें जिनसे skill सक्रिय नहीं होनी चाहिए, और जाँचें कि उन पर वह शांत रहती है या नहीं।

उस लूप को automate करने के लिए, official marketplace से skill-creator plugin install करें।

/plugin marketplace add anthropics/claude-plugins-official
/plugin install skill-creator@claude-plugins-official

यदि install output में Run /reload-plugins to activate. दिखाई दे, तो वह command चलाएँ। फिर Claude से अपनी skill का नाम लेकर उसका मूल्यांकन करने के लिए कहें। plugin test cases को skill directory के अंदर evals/evals.json में store करता है और प्रत्येक case को अपने स्वयं के subagent में चलाता है, इसलिए हर run एक साफ़ context के साथ शुरू होता है। फिर यह with-skill बनाम without-skill तुलना लिखता है, जो कि वास्तविक परिणाम है: skill की लागत और उसके द्वारा लिए गए tokens के मुकाबले pass rate में सुधार।

एक skill अपने साथ अपना प्रमाण भी रख सकती है, बजाय इसके कि उसे एक अलग eval run पर छोड़ दिया जाए, जो कि the Old Coder skill तब करती है जब वह agent से एक evidence report वापस दिलवाती है जिसे आप स्वयं फिर से चला सकते हैं।

Failure mode: skill trigger नहीं हो रहा है

आप request टाइप करते हैं, agent पुराना गलत काम करता है, और कोई skill line दिखाई नहीं देती है। इन बिंदुओं को क्रम से जाँचें।

• description में यह तो लिखा है कि skill क्या करती है, लेकिन यह नहीं बताया गया है कि इसे कब इस्तेमाल करना है, इसलिए आपकी request का कोई भी हिस्सा इससे मेल नहीं खाता।
• description में उन शब्दों का अभाव है जो आप टाइप कर रहे हैं। यदि आप "nginx" कहते हैं, तो description में nginx का उल्लेख होना आवश्यक है।
• frontmatter में disable-model-invocation: true सेट है। यह description को पूरी तरह से model के context से बाहर रखता है, और skill को केवल आपके द्वारा /name का उपयोग करके invoke करने योग्य बनाता है।
• frontmatter में एक paths glob activation को matching files तक सीमित करता है, और जिस file पर आप काम कर रहे हैं वह इससे मेल नहीं खाती।
• skill आपके starting directory के नीचे एक nested .claude/skills/ directory में स्थित है। वे केवल तभी load होती हैं जब agent उस subdirectory के अंदर किसी file को read या edit करता है, इसलिए तब तक skill बिल्कुल भी उपलब्ध नहीं होती है।

Failure mode: skill लगातार ट्रिगर होना

इसके विपरीत समस्या यह है कि description इतना व्यापक है कि skill असंबंधित कार्यों पर भी सक्रिय हो जाती है। "Use when working on the server" किसी भी server repository में लगभग हर request से मेल खा सकता है। इसके बाद body उन कार्यों पर लोड हो जाती है जिनमें यह मदद नहीं कर सकती, और यह session के बाकी समय के लिए context में बनी रहती है।

Description को उस स्थिति तक सीमित करें जो वास्तव में मायने रखती है, और उन files या commands के नाम बताएं जिन्हें यह कवर करती है। जब skill केवल कुछ विशिष्ट files पर लागू होती है, तो paths glob जोड़ें। Side effects वाले किसी भी कार्य के लिए, जैसे कि deploy या commit, disable-model-invocation: true सेट करें और इसे स्वयं /name के साथ invoke करें, ताकि agent कभी भी अपने आप यह निर्णय न ले कि अब deploy करने का सही समय है।

विफलता का प्रकार: skill आपके rules file का हिस्सा है

CLAUDE.md या AGENTS.md जैसी एक rules file हर session की शुरुआत में load होती है और हर task पर लागू होती है। एक skill body केवल तभी load होती है जब वह skill सक्रिय होती है। आवृत्ति (frequency) ही निर्णय का मुख्य आधार है। जो तथ्य repository के हर task के लिए सत्य है, जैसे कि आप कौन सा package manager उपयोग करते हैं, उसे rules file में होना चाहिए। जो प्रक्रिया tasks के एक छोटे हिस्से पर लागू होती है, जैसे कि ऊपर दी गई nginx rule, उसे एक skill में होना चाहिए, जहाँ उन दिनों इसका कोई खर्च नहीं होता जब कोई nginx को edit नहीं कर रहा होता।

असली विफलता इसे दोनों जगहों पर रखना है। दो प्रतियां (copies) समय के साथ अलग-अलग हो जाती हैं, और जब agent गलत काम करता है, तो आप यह नहीं बता सकते कि उसने किस प्रति का पालन किया। प्रत्येक निर्देश के लिए एक स्थान चुनें। यदि कोई नियम पहले से ही केवल एक स्थान पर है और फिर भी उसकी अनदेखी की जा रही है, तो यह एक अलग समस्या है, और ignored instruction के पीछे की कार्यप्रणाली को जांचना उचित है, इससे पहले कि आप इसे किसी skill में ले जाएं और यह उम्मीद करें कि स्थानांतरण से समस्या हल हो जाएगी। skills, MCP servers और rules files के बीच की सीमा कठिन मामलों का समाधान करती है, जिसमें यह भी शामिल है कि कब सही उत्तर एक MCP (model context protocol) server है, जो agent को नया निर्देश देने के बजाय एक नया tool प्रदान करता है।

जब यह अपनी जगह बना ले, तब इसे साझा करें

जो कौशल एक सप्ताह के वास्तविक काम में सफल रहता है, उसे सुरक्षित रखना सार्थक है। .claude/skills/ में प्रोजेक्ट स्किल्स की समीक्षा कोड की तरह की जाती है और वे रिपॉजिटरी के साथ ही आती हैं, इसलिए जो टीममेट इसे क्लोन करता है, उसे बिना किसी सेटअप चरण के आपका सुधार मिल जाता है। कॉपी और पेस्ट किए बिना रिपॉजिटरी के बीच कौशल को स्थानांतरित करना अपने आप में एक समस्या है, जिसे how to share agent skills across repos में कवर किया गया है।

पोर्टेबिलिटी के संबंध में एक नोट। Claude Code फ्रंटमैटर फील्ड्स की एक लंबी सूची स्वीकार करता है, लेकिन Agent Skills मानक केवल छह की अनुमति देता है: name, description, license, compatibility, metadata और allowed-tools। यदि आप किसी स्किल को claude.ai पर अपलोड करते हैं, या उसे Skills API के लिए पैकेज करते हैं, और फ्रंटमैटर में कुछ और भी शामिल करते हैं, तो यह फील्ड को अनदेखा करने के बजाय सीधे विफल हो जाता है:

Unexpected key(s) in SKILL.md frontmatter: argument-hint. Allowed properties are: allowed-tools, compatibility, description, license, metadata, name

उन छह फील्ड्स के भीतर ही रहें और वही फाइल Claude Code में और उस मानक को पढ़ने वाली हर दूसरी जगह लोड हो जाएगी। फाइल कहाँ लोड होती है, यह अभी भी तय करता है कि वह क्या कर सकती है, क्योंकि Cowork runs in an Anthropic sandbox while Claude Code runs on your own machine or VPS। इसलिए, ऊपर दी गई nginx स्किल को किसी टीममेट के चेकआउट में ले जाना सार्थक है, लेकिन ऐसे सैंडबॉक्स में यह व्यर्थ है जो सर्वर तक नहीं पहुँच सकता। निर्देशों को इस तरह लिखना कि वे किसी अन्य मॉडल में जाने पर भी काम करें, एक अलग कार्य है, और writing skills that work with any model इसे कवर करता है।

FAQ

SKILL.md फ़ाइल कितनी लंबी होनी चाहिए?

इसे 500 लाइनों से कम रखें, और उम्मीद करें कि अधिकांश उपयोगी स्किल्स इससे कहीं छोटी होंगी। जब स्किल को इनवोक किया जाता है, तो इसकी बॉडी बातचीत में शामिल हो जाती है और बाकी सेशन के दौरान वहीं रहती है, इसलिए हर लाइन एक बार की लागत के बजाय एक आवर्ती लागत (recurring cost) है। लंबी संदर्भ सामग्री को स्किल डायरेक्टरी में अलग फ़ाइलों में ले जाएं और उन्हें SKILL.md से लिंक करें, एक स्तर नीचे, ताकि एजेंट उन्हें केवल तभी पढ़े जब उसे उनकी आवश्यकता हो। बंडल की गई स्क्रिप्ट्स को पढ़ा नहीं बल्कि निष्पादित (execute) किया जाता है, इसलिए उनकी लागत केवल उनके आउटपुट के बराबर होती है।

मेरी स्किल ट्रिगर क्यों नहीं होती है?

इसका सामान्य कारण डिस्क्रिप्शन है, क्योंकि जब मॉडल निर्णय लेता है, तो केवल यही हिस्सा संदर्भ (context) में होता है। सुनिश्चित करें कि इसमें यह लिखा हो कि स्किल का उपयोग कब करना है, न कि केवल यह कि यह क्या करती है, और इसमें वे शब्द शामिल हों जिन्हें आप वास्तव में अपने अनुरोधों में टाइप करते हैं। यदि डिस्क्रिप्शन सही दिखता है, तो disable-model-invocation: true के लिए फ्रंटमैटर की जांच करें, जो स्किल को मॉडल से पूरी तरह छिपा देता है, और paths ग्लोब की जांच करें जो इसे उन फ़ाइलों तक सीमित करता है जिन्हें आप टच नहीं कर रहे हैं। आपकी शुरुआती डायरेक्टरी के नीचे एक नेस्टेड .claude/skills/ डायरेक्टरी में मौजूद स्किल एक और कारण है: यह केवल तभी लोड होती है जब एजेंट उस सबडायरेक्टरी में किसी फ़ाइल को पढ़ता या एडिट करता है।

क्या इसे एक स्किल होना चाहिए या मेरी रूल्स फ़ाइल की एक लाइन?

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

मुझे कैसे पता चलेगा कि स्किल ने वास्तव में मदद की?

इसकी तुलना एक बेसलाइन से करें। कुछ वास्तविक अनुरोध एकत्र करें, प्रत्येक को स्किल उपलब्ध होने के साथ एक नए सेशन में चलाएं, फिर उन्हें /skills मेनू से स्किल को बंद करके दोबारा चलाएं, और दोनों उत्तरों को साथ-साथ पढ़ें। एक नया सेशन मायने रखता है क्योंकि जिस बातचीत में आपने स्किल लिखी थी, उसमें अभी भी आपके स्पष्टीकरण मौजूद हैं, जो एक अधूरी फ़ाइल को पूर्ण दिखाते हैं। skill-creator प्लगइन आपके लिए यह तुलना चलाता है और टोकन लागत के साथ पास रेट की रिपोर्ट करता है।

क्या मैं एक ही SKILL.md का उपयोग अलग एजेंट के साथ कर सकता हूँ?

हाँ, जब तक आप उन फ़ील्ड्स के भीतर रहते हैं जिन्हें Agent Skills मानक परिभाषित करता है: name, description, license, compatibility, metadata और allowed-tools। Claude Code कई और फ़ील्ड्स को स्वीकार करता है, और यह बॉडी फीचर्स जैसे कि शेल कमांड इंजेक्शन का भी समर्थन करता है जिसे अन्य टूल्स रन नहीं करते हैं। मानक के बाहर के फ़ील्ड वाली स्किल को अपलोड करने पर एक स्पष्ट त्रुटि के साथ विफलता होती है जिसमें अनुमत प्रॉपर्टीज की सूची होती है, इसलिए जल्दी निर्णय लें कि क्या कोई स्किल Claude Code में रहने के लिए है या कहीं और ले जाने के लिए।