अपनी खुद की Agent Skill कैसे लिखें

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

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

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

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

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

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

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.

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

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

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

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

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

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

• .claude/skills/<name>/SKILL.md repository में: केवल इस 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 फाइल की सबसे महत्वपूर्ण पंक्ति है

स्टार्टअप के समय agent हर उपलब्ध skill के name और description को अपने context में लोड करता है। यह उनके bodies को लोड नहीं करता है। जब आपका 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 और example 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 लाइनों से कम रखें और विवरण को अलग फ़ाइलों में ले जाएं। कॉम्पैक्शन यह दर्शाता है कि यह संख्या मनमानी क्यों नहीं है। जब संदर्भ को खाली करने के लिए बातचीत का सारांश तैयार किया जाता है, तो Claude Code प्रत्येक skill के सबसे हालिया इनवोकेशन को फिर से अटैच करता है, प्रत्येक के केवल पहले 5,000 tokens रखता है, और सबसे हाल ही में invoke की गई skill से शुरू करके 25,000 tokens का संयुक्त बजट भरता है। एक लंबी skill बीच में ही कट जाती है। कई लंबी skills एक-दूसरे को पूरी तरह से बाहर धकेल देती हैं।

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

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

---
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 करने पर सही व्यवहार और अनुरोध करने पर गलत व्यवहार यह पुष्टि करता है कि समस्या instruction की नहीं, बल्कि trigger की है।
5. skill को बंद करके वही अनुरोध चलाएँ और दोनों उत्तरों की तुलना करें। /skills menu में, skill को highlight करें, उसकी स्थिति को off पर बदलने के लिए Space दबाएँ, फिर save करने के लिए Enter दबाएँ। यह .claude/settings.local.json में एक skillOverrides entry लिखता है, और काम पूरा होने पर Space को फिर से दबाने से यह वापस on पर आ जाता है।
6. कुछ ऐसे अनुरोध लिखें जिनसे skill सक्रिय नहीं होनी चाहिए, और जाँचें कि उन पर वह शांत रहती है या नहीं।

उस loop को 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 में सुधार।

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" सर्वर रिपॉजिटरी में लगभग किसी भी अनुरोध से मेल खा जाता है। इसके बाद body उन कार्यों पर लोड हो जाती है जिनमें यह मदद नहीं कर सकती, और यह session के बाकी हिस्से के लिए context में बनी रहती है।

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

Failure mode: skill आपके rules file का हिस्सा है

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

असली विफलता इसे दोनों जगहों पर रखना है। दो प्रतियां समय के साथ अलग-अलग हो जाती हैं, और जब agent गलत काम करता है, तो आप यह नहीं बता सकते कि उसने किस प्रति का पालन किया है। प्रत्येक निर्देश के लिए एक ही स्थान चुनें। 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 में और मानक को पढ़ने वाली हर दूसरी चीज़ में लोड हो जाएगी। निर्देशों को इस तरह लिखना कि वे किसी दूसरे मॉडल में जाने पर भी काम करें, एक अलग कार्य है, और writing skills that work with any model इसे कवर करता है।

FAQ

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

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

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

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

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

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

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

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

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

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