रेपोमध्ये agent skills share करण्याची योग्य पद्धत

रेपोमध्ये agent skills कशा share कराव्यात

रेपोमध्ये agent skills share करण्यासाठी फाइल कॉपी करणे थांबवा आणि तिच्यावर dependency म्हणून अवलंबून राहा. एक skills repository ठेवा, तिला tag द्या आणि प्रत्येक project मध्ये तो tag pin करा. त्यानंतर प्रत्येक skill साठी smoke test जोडा आणि प्रत्येक bump चे review dependency bump प्रमाणे करा.

यासाठी चार भाग आवश्यक आहेत: shared source of truth, प्रत्येक repository साठी pinned version, प्रत्येक skill साठी smoke test आणि review path. खालील सर्व मजकूर प्रत्येक भाग का आवश्यक आहे, 2026 मध्ये release होणारी tools याबाबत काय करतात आणि बाहेरील कोणतीही service न वापरता self-hosted git remote वर संपूर्ण रचना कशी तयार करायची हे स्पष्ट करतो.

An agent skill म्हणजे SKILL.md file असलेला folder आणि त्याला आवश्यक असलेल्या scripts व reference files. ही संकल्पना नवीन असल्यास, प्रथम agent skill म्हणजे काय आणि SKILL.md कसे कार्य करते हे वाचा. हे पृष्ठ त्या घटकाभोवतीच्या supply chain विषयी आहे.

स्किल कुठे असतो आणि तो शेअर करणे कठीण का असते

Claude Code तीन ठिकाणांहून skills लोड करते आणि skills documentation मध्ये प्रत्येक path दिलेला आहे.

• ~/.claude/skills/<skill-name>/SKILL.md वैयक्तिक असतो. तो तुमच्या सर्व projects मध्ये लोड होतो; इतर कोणाच्याही projects मध्ये नाही.
• .claude/skills/<skill-name>/SKILL.md हा project स्तरावरचा असतो. तो repository checkout करणाऱ्या प्रत्येक व्यक्तीसाठी लोड होतो.
• <plugin>/skills/<skill-name>/SKILL.md हा plugin मध्ये समाविष्ट असतो. तो plugin enable केलेल्या प्रत्येक ठिकाणी लोड होतो.

टीमसाठी मधला पर्याय उपयुक्त आहे, कारण तो commit केला जातो आणि repository clone करणाऱ्या प्रत्येकाला तो मिळतो. अडचणही इथूनच सुरू होते. .claude/skills/ मधील skill एका repository शी संबंधित असतो. तुमच्याकडे आठ repositories आहेत. त्यामुळे तो skill आठ वेळा copy केला जातो.

Frontmatter यासाठी कोणतीही मदत करत नाही. Agent Skills spec मध्ये सहा keys मान्य आहेत. आणखी एखादी key वापरल्यास ती अंमलात आणणारे distribution paths ही यादी दाखवतात:

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

यात काय नाही ते लक्षात घ्या: version key नाही. File मधील कोणतीही माहिती कोणती copy नवीन आहे हे नोंदवत नाही. हे योग्य आहे, कारण skill हा package नसून document आहे. त्यामुळे versioning file भोवतीच्या स्तरातून करावे लागते आणि तो स्तर व्यवस्थापित करणे तुमची जबाबदारी आहे.

समस्या 1: शांतपणे वेगळ्या होत जाणाऱ्या आठ प्रती

पहिल्या दिवशी copy-paste काम करते. साठाव्या दिवशी ती अपयशी ठरते. कोणी payments repo मधील चुकीची सूचना दुरुस्त करते, पण इतर सात प्रतींमध्ये बदल करत नाही. दुसरी व्यक्ती orders मध्ये pagination बाबत नियम जोडते. आता agent ज्या directory मधून सुरू झाला त्यानुसार समान skill name साठी दोन वेगवेगळी reviews मिळतात. याची जाणीव कोणत्याही developer ला होत नाही.

ही अडचण शांतपणे उद्भवते, कारण कोणतीही error state नसते. skill हा prose असतो. जुनी सूचना आत्मविश्वासपूर्ण पण चुकीचे उत्तर निर्माण करते. हीच सर्वात महागडी चूक असते. agent तुमच्या प्रतीची इतर कोणत्याही प्रतीशी तुलना करत नाही. त्यामुळे एकमेव संकेत म्हणजे दोन repo मध्ये विसंगती असल्याचे एखाद्या व्यक्तीच्या लक्षात येणे.

समस्या 2: कोणतीही आवृत्ती निश्चित केलेली नाही

एखादी टीम skills एकाच ठिकाणी ठेवत असली, तरी ती सामायिक करण्याची नेहमीची पद्धत म्हणजे copy step: setup script, onboarding doc मधील `curl` line किंवा folder sync करणारा shell alias. या सर्व पद्धती branch च्या सध्याच्या head वर असलेली आवृत्ती install करतात.

याचा अर्थ असा की, एकाच application च्या एकाच commit वर काम करणारे दोन developers वेगवेगळ्या instructions वापरत असू शकतात, कारण त्यांनी वेगवेगळ्या दिवशी sync चालवले. खराब agent run नंतर महत्त्वाच्या प्रश्नाचे उत्तरही देता येत नाही: हे कोणत्या skill version ने तयार केले? नोंदवलेली revision नसल्यास run reproducible राहत नाही. त्यामुळे bug report वर पुढील कारवाई करता येत नाही.

समस्या तीन: skill अजून कार्यरत आहे हे कोणालाच माहीत नसते

skill साठी compiler नसतो. ती model साठीच्या सूचना असतात. त्यामुळे file byte for byte समान राहिली तरी skill काम करणे थांबवू शकते. model upgrade मुळे दीर्घ instruction किती अचूकपणे पाळली जाते ते बदलते. skill ज्या command line tool ला call करते तो एखादा flag rename करतो. reference file मधील URL 404 देऊ लागतो आणि agent error page वरून काम करतो.

यापैकी कोणत्याही परिस्थितीत काहीही स्पष्टपणे fail होत नाही. agent अजूनही उत्तर देतो. मात्र ते उत्तर मागील महिन्यापेक्षा खराब असते. प्रत्येक pull request मध्ये थोडीशी घसरण होत असल्याने ती ओळखणे कठीण असते.

2026 मध्ये उपलब्ध होणारी साधने कोणत्या समस्या सोडवतात

अनेक उपाय सध्या उपलब्ध होत आहेत आणि आवृत्ती कुठे ठेवावी याबाबत त्यांची मते वेगवेगळी आहेत.

Lockfiles. Vercel Labs चे skills command line tool (vercel-labs/skills, MIT परवान्यासह, 5 August 2026 रोजी v1.5.22) git repository मधून skills install करून agent ला अपेक्षित असलेल्या कोणत्याही directory मध्ये ठेवते. तसेच ते सत्तरपेक्षा अधिक agents ची directory layout ओळखते. npx skills add <repo> install करते, npx skills update upgrade करते आणि npx skills list तुमच्याकडे काय install आहे ते दाखवते. Install केलेल्या गोष्टींची नोंद प्रत्येक repository साठी स्वतंत्रपणे न ठेवता प्रत्येक user साठी एकदाच ठेवली जाते. त्या project वरील open request (issue 283) मध्ये lock file मधून नोंदवलेल्या प्रत्येक skill ला पुन्हा install करणाऱ्या skills install command ची मागणी करण्यात आली आहे, ज्यामुळे दुसऱ्या machine वर तोच संच मिळेल. ही request स्थितीचा अहवाल म्हणून पाहा. Lockfile ची संकल्पना निश्चित झाली आहे. तिचा per-project भाग अजून तयार केला जात आहे.

Specs and tests. SkillSpec याच्या उलट दृष्टिकोनातून काम करते. ती SKILL.md वर विश्वास ठेवण्यासारखे prose न मानता तपासता येणारा contract मानते. Skills "followable, testable, and provable" करणे हे तिचे घोषित उद्दिष्ट आहे. skillspec doctor <path> agent कुठे संदर्भ गमावण्याची शक्यता आहे ते दाखवते. skillspec boundary map <path> skill कोणत्या गोष्टींपर्यंत पोहोचू शकते ते दाखवते आणि skillspec boundary assess <path> त्या निष्कर्षांना risk नुसार क्रम देते. हे Rust crate आहे. त्याला MIT किंवा Apache 2.0 यापैकी कोणताही परवाना लागू आहे. 29 July 2026 रोजी त्याची आवृत्ती 0.2.2 होती. नवीनतम आवृत्तीऐवजी निश्चित केलेली आवृत्ती install करा:

cargo install skillspec --version 0.2.2 --locked
skillspec --version

--locked crate प्रकाशित करताना वापरलेल्या dependency versions सह build करते. त्यामुळे build प्रक्रियेत अनपेक्षित बदल होत नाहीत. skillspec --version ने 0.2.2 दाखवले पाहिजे. वेगळी संख्या दिसल्यास तुमच्या PATH मध्ये आधी सापडणारी जुनी binary वापरली जात आहे.

Vendor practice. Google ने google/skills मधील skills कशा तयार केल्या जातात, याचे वर्णन how it builds, tests and scales agent skills या post मध्ये केले आहे. मोठ्या प्रमाणाचा भाग बाजूला ठेवला, तर ही पद्धत नेहमीच्या continuous integration (CI) वर आधारित आहे. प्रत्येक skill merge होण्यापूर्वी frontmatter metadata, line count, directory layout आणि naming यांसाठीच्या linters मधून तपासली जाते. कोणत्याही URL कडून 404 प्रतिसाद मिळाल्यास link checker build fail करते. त्यामुळे agent ने तयार केलेली दिसायला योग्य असलेली link पकडली जाते. Authors ने skill सोबत evaluation prompt suite आणि scoring rubric देणे आवश्यक आहे. त्यानंतर scheduled evaluation jobs संपूर्ण library वर दर आठवड्याला चालवले जातात, ज्यामुळे regressions शोधता येतात. तसेच प्रत्येक skill साठी named owner असतो आणि quality कमी झाल्यास त्याने ती दुरुस्त करणे अपेक्षित असते.

तीन्ही उत्तरांमागील समान रचना

तुम्हाला यांपैकी एक निवडण्याची गरज नाही. या सर्वांच्या मुळाशी एकच रचना आहे आणि plain git तुम्हाला ती पूर्णपणे उपलब्ध करून देते.

1. सत्याचा एकच स्रोत. प्रत्येक skill चे नेमके एकच ठिकाण असते आणि प्रत्येक repository प्रत ठेवण्याऐवजी त्या ठिकाणाचा संदर्भ देते.
2. प्रत्येक repository साठी निश्चित केलेली आवृत्ती. प्रत्येक प्रकल्प वापरत असलेली अचूक revision नोंदवतो. त्यामुळे upgrade म्हणजे त्या प्रकल्पातील author आणि date असलेला commit असतो.
3. प्रत्येक skill साठी smoke test. skill ने अपेक्षित परिणाम अजूनही तयार केला जातो हे सिद्ध करणारी एक चालवता येणारी तपासणी.
4. Review path. shared skill मधील बदल review प्रक्रियेतून जातो आणि प्रत्येक consumer तो स्वीकारण्यापूर्वी diff पाहतो.

हीच dependency ची रचना आहे. tooling त्याभोवती विकसित होण्यापेक्षा skills shared artifact म्हणून अधिक वेगाने विकसित झाली. त्यामुळे तुम्ही आधीपासून विश्वास ठेवत असलेले tooling वापरणे हा सर्वात सुरक्षित पर्याय आहे.

स्वतः होस्ट केलेल्या git remote वर लहान टीमसाठीची रचना

एका repository मध्ये skills ठेवले आहेत. त्यात इतर काहीही नाही. त्यामुळे त्याचा इतिहास सूचनांच्या changelog सारखा दिसतो.

agent-skills/
  skills/
    api-review/
      SKILL.md
    release-notes/
      SKILL.md
  tests/
    api-review.sh
    release-notes.sh
  CHANGELOG.md

Releases म्हणजे tags. Annotated tags वापरा, कारण त्यामध्ये message आणि date असतात. Message मध्ये consumer ला bump का हवा आहे ते लिहा:

git tag -a v1.4.0 -m "api-review: require pagination on list endpoints"
git push origin v1.4.0

तुमचा remote Gitea, Forgejo, GitLab किंवा तुमच्या स्वतःच्या VPS वरील SSH द्वारे bare repository असला, तरी पुढीलपैकी काहीही बदलत नाही. येथे सर्व काही git आणि एका symlink वर आधारित आहे.

git submodule वापरून पिन करणे

submodule तुमच्या repository मध्ये दुसऱ्या repository ची एक अचूक commit नोंदवतो. ही नोंद म्हणजे pin. प्रत्येक consuming project मध्ये:

git submodule add https://git.example.com/team/agent-skills.git vendor/agent-skills
git -C vendor/agent-skills fetch --tags
git -C vendor/agent-skills checkout v1.4.0
mkdir -p .claude/skills
ln -s ../../vendor/agent-skills/skills/api-review .claude/skills/api-review
git add .gitmodules vendor/agent-skills .claude/skills/api-review
git commit -m "Pin shared agent skills to v1.4.0"

हे काम symlink मुळे होते. Project स्तरावरील skill entry डिस्कवरील दुसऱ्या ठिकाणच्या directory कडे निर्देश करणारा symlink असू शकतो. Claude Code त्या symlink चे अनुसरण करतो आणि target मधून SKILL.md वाचतो. त्यामुळे skill नेहमीच्या project skill प्रमाणे लोड होते, परंतु तिचे bytes तुम्ही निवडलेल्या commit वरील submodule मध्ये राहतात.

Pin तपासा:

git submodule status

योग्य ओळीत सुरुवातीला एक space, त्यानंतर commit, मग path आणि शेवटी सर्वात जवळचा tag असतो:

 4d1a7c2f0b93e5a1c8d6f2b40e7a95c3d1f8b602 vendor/agent-skills (v1.4.0)

सुरुवातीला - असल्यास submodule कधीही initialise केलेले नाही. त्यामुळे .claude/skills/api-review कशाकडेही निर्देश करत नाही आणि skill शांतपणे लोड होत नाही. हे git submodule update --init वापरून दुरुस्त करा. सुरुवातीला + असल्यास checkout केलेली commit नोंदवलेल्या commit पेक्षा वेगळी आहे. त्यामुळे तो developer इतर कोणाकडेही नसलेल्या सूचना चालवत आहे. नवीन clone साठी git clone --recurse-submodules आवश्यक आहे. ही ओळ README मध्ये असली पाहिजे, कारण साधा clone केल्यास vendor/agent-skills रिकामे राहते आणि कोणतीही त्रुटी दाखवली जात नाही.

Upgrade जाणीवपूर्वक केले जाते. हाच त्याचा मुख्य उद्देश आहे:

git -C vendor/agent-skills fetch --tags
git -C vendor/agent-skills diff v1.4.0 v1.5.0 -- skills/
git -C vendor/agent-skills checkout v1.5.0
git add vendor/agent-skills
git commit -m "Bump shared agent skills to v1.5.0"

diff ओळ ही review साठीची पद्धत आहे. प्रत्येक consuming repo मध्ये दिसणारा तोच बदल ती दाखवते आणि तो pull request मध्ये समाविष्ट करता येतो.

प्लगइन marketplace ऐवजी pinning

प्रत्येक developer ला submodules शिकण्यास सांगायचे नसेल, तर Claude Code plugin system वितरणाची प्रक्रिया तुमच्यासाठी हाताळते आणि self-hosted remote सोबत कार्य करते. skills repository मध्ये `.claude-plugin/marketplace.json` येथे catalog ठेवा:

{
  "name": "acme-agents",
  "owner": { "name": "Platform team", "email": "platform@example.com" },
  "plugins": [
    {
      "name": "team-skills",
      "description": "Shared review and release skills",
      "version": "1.4.0",
      "source": {
        "source": "url",
        "url": "https://git.example.com/team/agent-skills.git",
        "ref": "v1.4.0",
        "sha": "4d1a7c2f0b93e5a1c8d6f2b40e7a95c3d1f8b602"
      }
    }
  ]
}

येथे दोन वेगळे sources कार्यरत आहेत. त्यांच्यात गोंधळ करणे ही सामान्य चूक आहे. Marketplace source म्हणजे catalog स्वतः कोठून fetch केला जातो ते. तो branch किंवा tag साठी `ref स्वीकारतो, पण sha स्वीकारत नाही. Catalog मधील plugin source मात्र दोन्ही स्वीकारतो. दोन्ही सेट केले असल्यास sha` ही प्रभावी pin असते. त्यामुळे exact-commit pin catalog entry मध्येच असली पाहिजे.

त्यानंतर प्रत्येक वापरणारे repository committed `.claude/settings.json` मध्ये marketplace घोषित करते:

{
  "extraKnownMarketplaces": {
    "acme-agents": {
      "source": {
        "source": "url",
        "url": "https://git.example.com/team/agent-skills.git",
        "ref": "v1.4.0"
      }
    }
  },
  "enabledPlugins": {
    "team-skills@acme-agents": true
  }
}

Project folder वर विश्वास ठेवणाऱ्या teammate ला marketplace install करण्याची सूचना मिळते. त्यामुळे ते करण्यास सांगणारे wiki page नसतानाही plugin त्यांच्यासाठी enable होतो. त्यानंतर skills `/team-skills:api-review ला प्रतिसाद देतात, कारण plugin skills plugin name नुसार namespaced असतात आणि त्याच नावाच्या project skill सोबत collision होऊ शकत नाही. नवीन tag push केल्यानंतर consumers /plugin marketplace update acme-agents ने refresh करतात. त्यानंतर install summary मध्ये तसे विचारले असल्यास /reload-plugins` चालवतात.

एका skill साठी smoke test लिहिणे

Smoke test म्हणजे ज्ञात fault असलेल्या fixture विरुद्ध scripted agent run आणि एक assertion. Claude Code -p सह non-interactive पद्धतीने चालते आणि user-invoked skill तिथे कार्य करते: prompt string मध्ये /skill-name ठेवल्यास run सुरू होण्यापूर्वी त्याचा विस्तार केला जातो.

#!/usr/bin/env bash
set -euo pipefail

claude -p "/api-review Read fixtures/orders-api.md and list the rule ids it breaks." \
  --allowedTools "Read" \
  --output-format json \
  --json-schema '{"type":"object","properties":{"rule_ids":{"type":"array","items":{"type":"string"}}},"required":["rule_ids"]}' \
  | jq -e '.structured_output.rule_ids | index("pagination-required")' > /dev/null

fixtures/orders-api.md ही एक लहान file आहे आणि त्यात एक जाणीवपूर्वक ठेवलेला fault आहे. त्या fault चे नाव skill देते, ही assertion आहे. filter मधून null निर्माण झाल्यास jq -e non-zero exit होते. त्यामुळे seeded fault शोधणे थांबवणारी skill script अयशस्वी करते. Run अयशस्वी झाल्यास claude स्वतः non-zero exit होते आणि set -euo pipefail या दोन्हीपैकी कोणत्याही failure चे रूपांतर failed test मध्ये करते.

वेगवेगळ्या run मध्ये model आपली उत्तरे वेगवेगळ्या शब्दांत मांडते. त्यामुळे पूर्ण वाक्यावर कधीही assertion लावू नका. Skill ने देणे अपेक्षित असलेल्या identifier वर किंवा तुम्ही मागितलेल्या schema मधील एखाद्या field वर assertion लावा. Run कमी खर्चात राहण्यासाठी fixture लहान ठेवा.

CI मध्ये --bare जोडा. हे नसल्यास claude -p interactive session मध्ये वापरला जाणारा तोच context लोड करते. त्यात hooks, plugins आणि मशीनवरील CLAUDE.md यांचाही समावेश असतो. त्यामुळे सहकाऱ्याच्या वैयक्तिक configuration मुळे निकाल बदलू शकतो. Bare mode सर्व auto-discovery वगळतो. त्यामुळे तुम्ही तपासत असलेली skill देखील वगळली जाते. म्हणून ती skill स्पष्टपणे load करा. Bare mode तुमचा subscription login देखील वाचत नाही. त्यामुळे आधी environment मध्ये ANTHROPIC_API_KEY सेट करा:

claude --bare -p "/team-skills:api-review Read fixtures/orders-api.md and list the rule ids it breaks." \
  --plugin-dir vendor/agent-skills \
  --allowedTools "Read" \
  --output-format json

--output-format stream-json सह run मधील पहिली event कोणते plugins load झाले हे सांगते आणि load न झालेल्या plugins साठी plugin_errors array देते. plugin_errors रिकामा नसल्यास CI job अयशस्वी करा. यामुळे अस्तित्वात नसलेल्या revision कडे निर्देश करणारा pin सापडतो. अन्यथा agent तुमचे house rules शांतपणे दुर्लक्षित करत असल्यासारखे दिसू शकते.

सामायिक skill म्हणजे कार्यान्वित करता येणारी सूचना

ही व्याख्या अक्षरशः लागू होते आणि file दुसऱ्या team कडून आली असेल, तर तिचे दोन्ही पैलू महत्त्वाचे ठरतात.

पहिले म्हणजे, SKILL.md model काहीही वाचण्यापूर्वी shell commands चालवू शकते. body मधील यासारखी line preprocessing करते:

- Current branch: !`git rev-parse --abbrev-ref HEAD`

ही command skill load करणाऱ्या machine वर चालते आणि तिचे output model ला मिळणाऱ्या text मधील placeholder ची जागा घेते. तीन backticks नंतर ! ने सुरू केलेला fenced block देखील याच प्रकारे अनेक commands चालवतो. रनटाइममध्ये यापैकी कोणत्याही कृतीसाठी कोणीही मंजुरी देत नाही. सामायिक skill वाचणे म्हणजे तिच्या command substitutions वाचणे होय.

दुसरे म्हणजे, frontmatter tools साठी पूर्वमंजुरी देऊ शकते. allowed-tools मध्ये नमूद केलेल्या tools ना त्या skill ला invoke करणाऱ्या turn साठी permission prompt न दाखवता परवानगी मिळते. project skill साठी, folder संदर्भातील workspace trust dialog कोणी स्वीकारल्यानंतर ही परवानगी लागू होते. Claude Code documentation मध्ये याचा परिणाम स्पष्टपणे सांगितला आहे: repository वर trust देण्यापूर्वी project skills चे पुनरावलोकन करा, कारण एखादी skill स्वतःला व्यापक tool access देऊ शकते.

म्हणून skill bump कडे dependency bump प्रमाणेच पाहा. mechanism परवानगी देत असेल तेथे exact commit ने pin करा, कारण tag बदलता येतो आणि branch ची व्याख्याच सतत बदलणारी असते. locked-down machine वर settings मधील "disableSkillShellExecution": true प्रत्येक command substitution चालवण्याऐवजी तिच्या जागी literal text [shell command execution disabled by policy] ठेवते. managed settings द्वारे लागू केल्यास user ते override करू शकत नाही. Bundled आणि managed skills या setting मधून exempt आहेत.

skill काय वाचते, याबाबतही अशीच काळजी घ्या. env चालवणारी किंवा config file उघडणारी skill तिला सापडणारी कोणतीही माहिती model च्या context मध्ये आणते. हीच समस्या तुम्ही चालवत असलेल्या agents पासून secrets दूर ठेवणे या भागात स्पष्ट केली आहे. एखादी skill page fetch करते किंवा query चालवते, तेव्हा हाच exposure बाहेरच्या दिशेने होतो. Retrieved text तुम्ही लिहिलेल्या instructions प्रमाणेच context मध्ये येतो. म्हणून web search साठी तुमच्या स्वतःच्या SearXNG instance कडे agent ला निर्देशित करणे यापूर्वी ही boundary समजून घेणे महत्त्वाचे आहे.

आवृत्ती बदलताना काय वाचावे

• प्रत्येक SKILL.md body मधील diff, कारण तुमचा agent ज्या सूचनांचे पालन करेल तो मजकूर तिथे असतो.
• प्रत्येक command substitution, कारण skill load होताना ते तुमच्या machine वर चालतात.
• allowed-tools मधील कोणताही बदल, कारण त्या ओळीमुळे prompt शिवाय tools वापरण्याची परवानगी मिळते.
• tag मागे चालवलेली test run. Shared repository स्वतःचे smoke tests CI मध्ये चालवत असल्यास, तुम्ही pin केलेल्या tag सोबत green run जोडलेली असावी.

दहा मिनिटांत संपूर्ण diff वाचता येत नसेल, तर reviewer ज्या skill कडे पाहत आहे ती खूप मोठी झाली आहे. तिचे विभाजन करा. हाच मुद्दा तुमचे agents वाचत असलेल्या repository documentsनाही लागू होतो: टिकाऊ नियम AGENTS.md आणि HUMAN.md चे विभाजन मध्ये वर्णन केलेल्या files मध्ये ठेवा, architectural reasoning agents साठी लिहिलेल्या DESIGN.md मध्ये ठेवा आणि skillsना मर्यादित procedures म्हणून ठेवावे.

मॉडेल किंवा tool मधील बदलामुळे skill काम करणे थांबते

कोणीही skill मध्ये बदल न करता तिच्या अंतर्गत अनेक गोष्टी बदलू शकतात. मॉडेलच्या upgrade मुळे दीर्घ instruction चे पालन किती विश्वासार्हपणे होते ते बदलते. त्यामुळे मॉडेलने नवव्या step पर्यंत पोहोचण्यावर अवलंबून असलेली skill तिथपर्यंत पोहोचणे थांबवू शकते. Command line tool मधील flag चे नाव बदलल्यास agent जुना flag चालवतो, error वाचतो आणि स्वतःहून दुसरी कृती करतो. संदर्भित URL 404 देऊ लागतो. Agent harness skills कशा निवडतो त्यात बदल झाल्यास पूर्वी match जिंकणारा description आता जिंकत नाही. Procedure अशा प्रकारे लवकर समाप्त होऊ लागल्यावर कोणताही version bump ही समस्या सोडवत नाही. Instructions मध्ये शेवटच्या steps पर्यंत पोहोचणे सक्तीचे करणारी रचना आवश्यक असते. unlazy skill आणि तिची Depth Tree पद्धत याच दृष्टिकोनावर आधारित आहे.

म्हणूनच या व्यवस्थेत smoke test महत्त्वाची भूमिका बजावते. प्रत्येक skill ची test नियोजित वेळापत्रकानुसार तसेच push वेळी चालवा. Google याच कारणासाठी संपूर्ण library विरुद्ध आपली evaluation jobs दर आठवड्याला चालवते. दहा skills असलेल्या team साठी छोट्या VPS वर weekly cron job पुरेसा असतो. Developer ला समस्या आढळण्यापूर्वी breakage कळण्याचा हा एकमेव मार्ग आहे.

Portability देखील उपयुक्त ठरते. Agent Skills spec मध्ये frontmatter सहा keys पर्यंत मर्यादित ठेवले आहे. त्यामुळे त्या spec नुसार लिहिलेली skill ज्या tool साठी लिहिली आहे त्यापलीकडील tools मध्येही load होते. याउलट, तुम्ही जोडलेली प्रत्येक harness-specific key ही एका vendor वर अवलंबून राहण्याचा निर्णय असतो. मॉडेल बदलल्यानंतरही कार्यरत राहतील अशा skills लिहिणे ही स्वतंत्र शिस्त आहे. तिचे वर्णन कोणत्याही model वर skill कार्यरत कशी करावी येथे केले आहे.

FAQ

अनेक repositoriesमध्ये एकच agent skill कशी share करू?

skill स्वतंत्र git repositoryमध्ये ठेवा, त्यामध्ये releases tag करा आणि प्रत्येक वापरणाऱ्या project मध्ये file कॉपी करण्याऐवजी tagचा reference द्या. यासाठी दोन पद्धती वापरता येतात. git submodule अचूक commit नोंदवतो आणि .claude/skills/<name> मधून submoduleकडे असलेली symlink तो skill सामान्य project skill म्हणून load करते. Plugin marketplace हेच काम /plugin द्वारे करते; त्यामधील pin वापरणाऱ्या repositoryच्या .claude/settings.json मध्ये घोषित केला जातो. दोन्ही पद्धतींमध्ये version git historyमध्ये नोंदवली जाते. त्यामुळे एखाद्या agent run साठी कोणत्या instructions वापरल्या गेल्या हे निश्चित करता येते.

agent skillला विशिष्ट versionवर pin करता येते का?

SKILL.md मधून करता येत नाही, कारण त्या frontmatterमध्ये version key नाही. हा pin fileभोवतालच्या layerमधून द्यावा लागतो. git submodule रचनेनुसार अचूक commit pin करतो. Claude Code plugin marketplaceमध्ये plugin source branch किंवा tagसाठी ref आणि अचूक commitसाठी sha स्वीकारतो. दोन्ही उपस्थित असल्यास sha ला प्राधान्य मिळते. Marketplace source स्वतः फक्त ref स्वीकारतो. Commit pin वापरणे अधिक सुरक्षित आहे, कारण तुम्ही तपासल्यानंतर tag हलवता येतो.

skillच्या smoke testमध्ये कोणत्या गोष्टी assert कराव्यात?

स्थिर परिणामावर assert करा. ज्ञात fault असलेल्या fixtureवर skill non-interactively चालवा. त्यानंतर outputमध्ये विशिष्ट identifier दिसतो का ते तपासा. उदाहरणार्थ, skillने report करणे अपेक्षित असलेला rule id तपासा. --output-format json आणि --json-schema वापरून structured output मागवल्यास check अचूक होते. मूल्य missing असल्यास jq -e script fail करते. पूर्ण sentenceवर कधीही assert करू नका. Model प्रत्येक runमध्ये उत्तराची मांडणी बदलू शकते.

दुसऱ्या teamच्या repositoryमधून shared skill install करणे सुरक्षित आहे का?

त्याला code dependency समजा, कारण तो executable instruction आहे. SKILL.md load होताना ! command substitution formद्वारे shell commands चालवू शकतो. तसेच frontmatterमधील allowed-tools field prompt न दाखवता toolsना पूर्वमान्यता देऊ शकते. प्रत्येक bumpवेळी diff तपासा. Branchऐवजी अचूक commitवर pin करा. तुमची स्वतःची team नियंत्रित करत असलेल्या sourceला प्राधान्य द्या. Managed machinesवर settingsमधील "disableSkillShellExecution": true command substitutions पूर्णपणे चालू होण्यापासून रोखते.

Claude Codeव्यतिरिक्त इतर agentsमध्ये shared skill कार्य करेल का?

तुम्ही कोणते frontmatter वापरता यावर ते अवलंबून आहे. Agent Skills specमध्ये सहा keys परिभाषित केल्या आहेत: name, description, license, compatibility, metadata आणि allowed-tools. फक्त या keysपुरता मर्यादित skill spec implement करणाऱ्या toolsमध्ये load होतो. तो Claude Codeमध्येही कोणताही बदल न करता load होतो. Harness-specific keys आणि specबाहेरील body features इतरत्र ignore किंवा reject केली जाऊ शकतात. त्यामुळे मोठ्या प्रमाणावर share करायच्या skillमध्ये ती वापरू नका.