स्वतःचे agent skill कसे लिहावे?

एका प्रत्यक्ष अपयशातून स्वतःचे agent skill लिहा

स्वतःचे agent skill लिहिण्याचा सर्वोत्तम मार्ग म्हणजे ते एका प्रत्यक्ष अपयशातून तयार करणे. तुमच्या coding agent ने दोनदा चुकीचे केलेले एखादे काम शोधा, दोन्ही वेळा तुम्ही टाइप केलेली दुरुस्ती लिहून ठेवा आणि ती दुरुस्ती agent स्वतः लोड करू शकेल अशा SKILL.md फाइलमध्ये जतन करा. त्यानंतरची सर्व प्रक्रिया तांत्रिक आहे: फाइलची मांडणी आणि skill सक्रिय होईल की नाही हे ठरवणारी एक ओळ.

हा क्रम महत्त्वाचा आहे. कल्पनेतून लिहिलेला skill तुम्हाला कधीच आलेली नसलेली समस्या नोंदवतो आणि प्रत्येक session मध्ये context वापरतो. प्रत्यक्ष पाहिलेल्या अपयशातून तयार केलेल्या skill सोबत त्याची चाचणीही तयार असते: पुन्हा तोच प्रश्न विचारा आणि यावेळी agent योग्य उत्तर देतो का ते तपासा. हा format तुमच्यासाठी नवीन असल्यास, आधी agent skills म्हणजे काय आणि agent ते कसे लोड करतो वाचा. त्यानंतर परत येऊन एक skill लिहा.

एजंटने दोनदा चुकीचे केलेल्या कामापासून सुरुवात करा

एकदा घडणे हा योगायोग असू शकतो. दोनदा घडणे ही पद्धत असते आणि अशा पद्धतीची नोंद फाइलमध्ये ठेवणे आवश्यक असते.

खऱ्या सर्व्हरवर वारंवार दिसणारे एक अपयश पाहू. तुम्ही एजंटला nginx मध्ये reverse proxy block जोडण्यास सांगता. तो /etc/nginx/conf.d/app.conf संपादित करतो आणि नंतर sudo systemctl restart nginx चालवतो. संपादनात टायपो असल्यामुळे 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 वापरून configuration तपासा. त्यानंतर restart ऐवजी reload वापरून ते लागू करा. एका आठवड्यानंतर, वेगळ्या कामात तीच चूक पुन्हा होते. दुसऱ्यांदा घडणे हा संकेत आहे.

अपयश अजून समोर असतानाच दोन गोष्टी लिहून ठेवा: तुम्ही टाइप केलेली विनंती आणि तुम्ही दिलेली दुरुस्ती, तुम्ही वापरलेल्या शब्दांत. या दोन ओळी skill बनतात. विनंतीत trigger ने कशाशी जुळले पाहिजे हे स्पष्ट होते. दुरुस्तीमध्ये skill ची संपूर्ण सामग्री असते.

Anthropic च्या स्वतःच्या authoring guidance मध्येही हे प्रथम करण्यास सांगितले आहे. कोणतेही skill न वापरता representative tasks वर एजंट चालवा आणि तो कुठे अपयशी ठरतो ते नोंदवा. त्यानंतर ती अपयशे दुरुस्त करणाऱ्या किमान सूचना लिहा. अपयशे हीच specification असतात. त्यामुळे एखाद्या अपयशाशी trace करता न येणारे skill सहसा कोणालाही आवश्यक नसते.

याच 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 मध्ये काही settings लिहिलेल्या असतात. Docker Compose files मध्येही हेच configuration format वापरले जाते. त्यानंतर markdown मध्ये instructions असतात. वरील failure साठीची संपूर्ण 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 वीस lines पेक्षा लहान आहे आणि ती एक पूर्ण skill आहे. तिचे भाग पुढीलप्रमाणे आहेत:

• name: जास्तीत जास्त 64 characters. यात फक्त lowercase letters, digits आणि hyphens असू शकतात. यात claude किंवा anthropic हे शब्द असू शकत नाहीत. Personal किंवा project skill मध्ये हे केवळ display label असते. तुम्ही टाइप केलेला command directory name वरून येतो. त्यामुळे ही skill /nginx-config-changes नावाने वापरता येते.
• description: skill काय करते आणि ती कधी वापरायची, याचे वर्णन. कमाल 1,024 characters. ही line प्रत्यक्ष काम करते. पुढील section मध्ये याच विषयाशिवाय दुसरे काही नसते.
• Body: instructions. Skill प्रत्यक्ष सक्रिय झाल्यावरच त्या load केल्या जातात.
• reference/: agent मागणीनुसार वाचतो अशा अतिरिक्त files. त्यांना SKILL.md मधून link करा आणि links एकाच स्तरावर ठेवा. Referenced file मधून आणखी एखादी file reference केल्यास ती अनेकदा अंशतःच वाचली जाते.
• scripts/: agent वाचण्याऐवजी execute करतो अशा files. Context साठी फक्त त्यांचा output मोजला जातो. त्यामुळे 300 lines ची script स्वस्त ठरते.

Directory कुठे ठेवता यावर ही skill कोण वापरू शकतो ते ठरते.

• Repository मधील .claude/skills/<name>/SKILL.md: फक्त या project साठी. Repository clone करणाऱ्या प्रत्येकाकडे ती उपलब्ध होते.
• ~/.claude/skills/<name>/SKILL.md: तुमच्या machine वरील प्रत्येक project साठी. इतर कोणाच्याही machine वर ती उपलब्ध नसते.
• <plugin>/skills/<name>/SKILL.md: plugin मध्ये समाविष्ट केलेली. तो plugin enabled असलेल्या प्रत्येक ठिकाणी ती उपलब्ध असते.

mkdir -p .claude/skills/nginx-config-changes वापरून directory तयार करा आणि file लिहा. Claude Code या directories वर लक्ष ठेवते. त्यामुळे विद्यमान skill edit केल्यास ती बदल running session मध्ये लागू होतो. Session सुरू झाला तेव्हा अस्तित्वात नसलेली top-level skills directory तयार केल्यास restart आवश्यक आहे. Session सुरू होताना तिच्यावर लक्ष ठेवण्यासाठी काहीच अस्तित्वात नव्हते.

फाइलमधील description field ही सर्वाधिक परिणामकारक ओळ आहे

सुरू होताना agent उपलब्ध असलेल्या प्रत्येक skill चे name आणि description आपल्या context मध्ये लोड करतो. तो skill चे bodies लोड करत नाही. तुमची request आल्यावर हा skill संबंधित आहे की नाही हे ठरवण्यासाठी त्या एकाच ओळीचा संपूर्ण आधार घेतला जातो. त्यामुळे अस्पष्ट description मागे असलेला उत्तम body कधीही वाचला जात नाही.

description तृतीय पुरुषी लिहा. Tests and reloads nginx safely हे योग्य आहे. I can help you with nginx हे योग्य नाही, कारण हा मजकूर system prompt मध्ये inject केला जातो. अशा ठिकाणी प्रथमपुरुषी वाक्य model स्वतःबद्दल बोलत असल्यासारखे वाचले जाते.

description मध्ये दोन गोष्टी ठेवा: skill काय करतो आणि तो कोणत्या परिस्थितीत लागू होतो. महत्त्वाचा use case प्रथम लिहा, कारण Claude Code listing entry 1,536 characters वर truncate करतो. अतिरिक्त trigger phrases आणि example requests साठी पर्यायी when_to_use field उपलब्ध आहे. तो याच मर्यादेत description नंतर जोडला जातो.

त्यानंतर तुम्ही प्रत्यक्षात type करणार असलेले शब्द वापरा. description: Helps with nginx कशाशीही जुळत नाही, कारण कोणीही helps with असे type करत नाही. वरील आवृत्तीत /etc/nginx, server block, reverse proxy आणि TLS (transport layer security) certificate path यांचा उल्लेख आहे. एखाद्या request ने हा skill trigger करण्यासाठी आवश्यक असलेल्या शब्दसंग्रहाशी हे साधारणपणे जुळते.

description साठी ही चाचणी करा. body कधीही न पाहिलेल्या व्यक्तीला ती एक ओळ द्या आणि त्यासोबत तुम्ही type करणार असलेली request द्या. त्याला skill लागू होतो का ते विचारा. तो ठरवू शकत नसेल, तर model देखील ठरवू शकणार नाही.

मजकूर लहान ठेवा, कारण तो context मध्ये राहतो

skill invoke केल्यावर त्यातील render केलेला मजकूर एका message म्हणून conversation मध्ये येतो आणि session संपेपर्यंत तिथेच राहतो. Claude Code पुढील turns मध्ये ती file पुन्हा read करत नाही. तुम्ही लिहिलेली प्रत्येक line केवळ एका answer साठी नव्हे, तर संपूर्ण session साठी लागणारी किंमत असते.

Anthropic SKILL.md 500 lines पेक्षा कमी ठेवण्याची आणि सविस्तर माहिती स्वतंत्र files मध्ये हलवण्याची शिफारस करते. Compaction यामागचे कारण स्पष्ट करते. Context मोकळा करण्यासाठी conversation चे summary तयार केल्यावर Claude Code प्रत्येक skill चे सर्वात अलीकडील invocation पुन्हा जोडतो, प्रत्येकातील फक्त पहिले 5,000 tokens ठेवतो आणि एकत्रित 25,000 tokens चा budget सर्वात अलीकडे invoke केलेल्या skill पासून भरतो. मोठ्या skill चा मजकूर मध्येच truncate होतो. अनेक मोठ्या skills मुळे त्या एकमेकींना पूर्णपणे बाहेर ढकलू शकतात.

म्हणून model ला आधीपासून माहीत नसलेलीच माहिती लिहा. nginx काय आहे आणि reverse proxy काय करतो हे त्याला माहीत असते. reload हे restart पेक्षा जास्त असावे असा तुमचा स्थानिक नियम त्याला माहीत नसतो; ही file असण्याचे एकमेव कारण तो नियम आहे.

skill ने agent ला bundled script चालवण्यास सांगितले असल्यास, path मध्ये ${CLAUDE_SKILL_DIR} वापरा, म्हणजे skill जिथे install केले असेल तिथे तो योग्य प्रकारे resolve होईल. तसेच त्याच command ला आधीच approve करा, म्हणजे permission prompt मुळे run थांबणार नाही.

---
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 केलेल्या turn पुरते असते आणि तुम्ही पुढील message पाठवल्यावर ते clear होते. त्यामुळे ती नकळत permanent permission बनत नाही.

कौशल्य कार्यान्वित होत असल्याचे कसे सिद्ध करावे

कौशल्य लोड होताना पाहिल्याने एजंटला ते सापडल्याचे कळते. मात्र त्यातून उत्तर बदलले आहे असे सिद्ध होत नाही. दोन्ही गोष्टी तपासा. ही चाचणी नवीन session मध्ये करा, कारण ज्या session मध्ये तुम्ही कौशल्य लिहिले आहे त्यात लेखनादरम्यान दिलेली सर्व माहिती आधीपासून उपलब्ध असते. त्या उरलेल्या context मुळे फाइलमधील त्रुटी लक्षात येत नाहीत.

1. प्रोजेक्टमध्ये claude वापरून नवीन session सुरू करा.
2. कौशल्याचे नाव न सांगता, नेहमीच्या कामाच्या दिवशी जशी विनंती कराल तशी, स्वतःच्या शब्दांत विनंती लिहा.
3. कौशल्य invoke झाले आहे का ते पाहा. कौशल्य कार्यान्वित झाले नाही, तर description दुरुस्त करा. सध्या body ही समस्या नाही.
4. नियंत्रण चाचणी म्हणून /nginx-config-changes वापरून ते स्वतः invoke करा. स्वतः invoke केल्यावर योग्य वर्तन आणि विनंती केल्यावर चुकीचे वर्तन दिसल्यास समस्या instruction मध्ये नसून trigger मध्ये आहे, असे स्पष्ट होते.
5. कौशल्य बंद करून तीच विनंती पुन्हा चालवा आणि दोन्ही उत्तरे तुलना करा. /skills मेनूमध्ये कौशल्य highlight करा आणि Space दाबून त्याची स्थिती off वर बदला. त्यानंतर जतन करण्यासाठी Enter दाबा. यामुळे .claude/settings.local.json मध्ये skillOverrides entry लिहिली जाते. काम पूर्ण झाल्यावर Space पुन्हा दाबल्यास स्थिती on वर परत जाते.
6. कौशल्य कार्यान्वित होऊ नयेत अशा काही विनंत्या लिहा आणि त्यावर ते शांत राहते का ते तपासा.

ही प्रक्रिया स्वयंचलित करण्यासाठी अधिकृत 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 ला तुमच्या कौशल्याचे नाव सांगून त्याचे मूल्यमापन करण्यास सांगा. plugin प्रत्येक test case कौशल्याच्या directory मधील evals/evals.json मध्ये साठवतो आणि प्रत्येक case स्वतंत्र subagent मध्ये चालवतो. त्यामुळे प्रत्येक run स्वच्छ context पासून सुरू होतो. त्यानंतर तो with-skill आणि without-skill यांची तुलना लिहितो. हीच प्रामाणिक मोजणी आहे: कौशल्यासाठी लागणाऱ्या tokens आणि वेळेच्या तुलनेत pass rate मध्ये झालेली सुधारणा.

अपयशाची स्थिती: skill कधीच सक्रिय होत नाही

तुम्ही विनंती लिहिता, agent जुने चुकीचे काम करतो आणि skill ची कोणतीही ओळ दिसत नाही. खालील कारणे क्रमाने तपासा.

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

अपयशाची स्थिती: skill सतत सक्रिय होते

याच्या उलट समस्या अशी असते की description इतके व्यापक असते की skill असंबंधित कामांवरही सक्रिय होते. "सर्व्हरवर काम करताना वापरा" हे server repository मधील जवळपास कोणत्याही विनंतीशी जुळते. त्यानंतर body अशा task वर load होते ज्यात ते उपयुक्त ठरू शकत नाही, आणि उर्वरित session साठी ते context मध्ये राहते.

प्रत्यक्षात महत्त्वाच्या असलेल्या condition पर्यंत description मर्यादित करा आणि त्यात लागू असलेल्या files किंवा commands नमूद करा. skill फक्त विशिष्ट files साठी लागू असल्यास paths glob जोडा. deploy किंवा commit यांसारख्या side effects असलेल्या कोणत्याही कृतीसाठी disable-model-invocation: true सेट करा आणि /name वापरून ती स्वतः invoke करा. त्यामुळे deploy करण्यासाठी ही योग्य वेळ आहे असे agent स्वतःहून ठरवणार नाही.

Failure mode: the skill belongs in your rules file

अपयशाची स्थिती: skill तुमच्या rules file मध्ये असणे आवश्यक आहे

CLAUDE.md किंवा AGENTS.md सारखी rules file प्रत्येक session च्या सुरुवातीला लोड होते आणि प्रत्येक task ला लागू होते. skill body फक्त skill सक्रिय झाल्यावर लोड होते. निर्णयासाठी frequency हा मुख्य निकष आहे. Repository मधील प्रत्येक task ला लागू होणारी माहिती, जसे की तुम्ही वापरत असलेला package manager, rules file मध्ये असावी. nginx rule सारखी मोजक्या task ला लागू होणारी procedure skill मध्ये असावी. ज्या दिवशी nginx मध्ये कोणीही बदल करत नाही, त्या दिवशी तिचा कोणताही अतिरिक्त खर्च होत नाही.

तीच instruction दोन्ही ठिकाणी ठेवणे हे खरे अपयश आहे. दोन प्रती कालांतराने वेगळ्या होतात. Agent चुकीची कृती करतो तेव्हा त्याने कोणती प्रत अनुसरली हे कळत नाही. प्रत्येक instruction साठी एकच योग्य स्थान निवडा. skills, MCP servers आणि rules files यांच्यातील सीमा अधिक कठीण परिस्थितींमध्येही मार्गदर्शन करते. त्यात योग्य उत्तर नवीन instruction ऐवजी agent ला नवीन tool देणारा MCP (model context protocol) server असण्याची परिस्थितीही समाविष्ट आहे.

प्रत्यक्ष उपयुक्तता सिद्ध झाल्यावर ती सामायिक करा

प्रत्यक्ष कामात एक आठवडा टिकणारे skill commit करण्यास योग्य असते. .claude/skills/ मधील project skills चे code प्रमाणे परीक्षण केले जाते आणि ते repository सोबत येतात. त्यामुळे repository clone करणाऱ्या सहकाऱ्याला तुमची सुधारणा कोणतीही setup पायरी न करता मिळते. copy आणि paste न करता एखादे skill एका repository मधून दुसऱ्या repository मध्ये हलवणे ही स्वतंत्र समस्या आहे. तिचे वर्णन repositories मध्ये agent skills कसे सामायिक करावे येथे केले आहे.

Portability बाबत एक सूचना. Claude Code मध्ये frontmatter fields ची मोठी यादी स्वीकारली जाते. मात्र Agent Skills standard मध्ये फक्त सहा fields अनुमत आहेत: name, description, license, compatibility, metadata आणि allowed-tools. frontmatter मध्ये यांव्यतिरिक्त काहीही ठेवून skill claude.ai वर upload केले किंवा Skills API साठी package केले, तर field दुर्लक्षित न करता प्रक्रिया थेट अयशस्वी होते:

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

या सहा fields पुरतेच मर्यादित राहिल्यास तीच file Claude Code मध्ये आणि हा standard वाचणाऱ्या इतर सर्व साधनांमध्ये load होते. instructions स्वतः अशा प्रकारे लिहिणे की ते वेगळ्या model वर हलवल्यानंतरही कार्यरत राहतील, हे स्वतंत्र काम आहे. त्यासाठी कोणत्याही model सोबत कार्य करणारी skills कशी लिहावीत हे पहा.

FAQ

SKILL.md फाइल किती लांब असावी?

ती 500 ओळींपेक्षा कमी ठेवा. बहुतेक उपयुक्त skills यापेक्षा खूपच लहान असतात. Skill invoke केल्यावर तिचा body conversation मध्ये येतो आणि उर्वरित sessionभर तिथेच राहतो. त्यामुळे प्रत्येक ओळ ही एकदाच होणारा खर्च नसून पुन्हा पुन्हा होणारा खर्च असतो. दीर्घ reference material skill directory मधील स्वतंत्र फाइलमध्ये हलवा आणि SKILL.md मधून त्याची link द्या. ही रचना एकाच स्तरापर्यंत ठेवा, जेणेकरून agent ला ती सामग्री गरज असेल तेव्हाच वाचावी लागेल. Bundled scripts वाचण्याऐवजी execute केल्या जातात. त्यामुळे त्यांचा खर्च फक्त त्यांच्या output पुरता असतो.

माझे skill कधीच trigger का होत नाही?

सामान्यतः description हे कारण असते. Model निर्णय घेताना skill चा context मध्ये असलेला हा एकमेव भाग असतो. Description मध्ये skill काय करते एवढेच नव्हे, तर ती कधी वापरायची हेही स्पष्ट असले पाहिजे. तुमच्या requests मध्ये तुम्ही प्रत्यक्ष वापरता ते शब्दही त्यात असले पाहिजेत. Description योग्य दिसत असल्यास frontmatter मध्ये disable-model-invocation: true आहे का ते तपासा. ते skill model पासून पूर्णपणे लपवते. तसेच, तुम्ही वापरत नसलेल्या files पर्यंत मर्यादा घालणारा paths glob आहे का ते तपासा. तुमच्या starting directory खालील nested .claude/skills/ directory मधील skill हेदेखील कारण असू शकते. त्या subdirectory मधील file agent वाचल्यानंतर किंवा edit केल्यानंतरच ते load होते.

हे skill असावे की माझ्या rules file मधील एक ओळ?

ते तुमच्या किती tasks ला लागू होते हे पाहा. Rules file प्रत्येक session मध्ये load होते. त्यामुळे package manager किंवा branch naming convention यांसारखी प्रत्येक task साठी खरी असलेली माहिती त्यात असावी. Skill फक्त trigger झाल्यावर load होते. त्यामुळे कमी प्रमाणातील tasks साठी महत्त्वाची असलेली procedure ठेवण्यासाठी ते योग्य ठिकाण आहे. एकच instruction दोन्ही ठिकाणी कधीही लिहू नका. दोन्ही copies मध्ये कालांतराने फरक पडतो आणि agent ने कोणती copy follow केली हे ठरवणे कठीण होते.

Skill ने प्रत्यक्ष मदत केली हे मला कसे कळेल?

त्याची baseline शी तुलना करा. काही वास्तविक requests जमा करा. Skill उपलब्ध असलेल्या fresh session मध्ये प्रत्येक request चालवा. त्यानंतर /skills menu मधून skill बंद करून तेच requests पुन्हा चालवा. दोन्ही answers समोरासमोर वाचा. Fresh session महत्त्वाचे आहे, कारण तुम्ही skill लिहिलेल्या conversation मध्ये तुमची explanations अजूनही असतात. त्यामुळे अपूर्ण file पूर्ण असल्यासारखी दिसू शकते. skill-creator plugin ही तुलना तुमच्यासाठी करते आणि token cost च्या शेजारी pass rate दाखवते.

मी तेच SKILL.md वेगळ्या agent सोबत वापरू शकतो का?

होय, परंतु Agent Skills standard ने परिभाषित केलेल्या fields मध्येच राहा: name, description, license, compatibility, metadata आणि allowed-tools. Claude Code मध्ये आणखी अनेक fields स्वीकारले जातात. तसेच, इतर tools चालवत नाहीत अशा shell command injection सारख्या body features चेही ते समर्थन करते. Standard च्या बाहेरील field असलेले skill upload केल्यास, अनुमत properties ची यादी देणाऱ्या स्पष्ट error सह प्रक्रिया अयशस्वी होते. त्यामुळे skill फक्त Claude Code मध्ये ठेवायचे आहे की वेगवेगळ्या tools मध्ये वापरायचे आहे, हे सुरुवातीलाच ठरवा.