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

विविध repos मध्ये agent skills कशा share कराव्यात

विविध repos मध्ये 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 मध्ये उपलब्ध tools त्याबाबत काय करतात आणि बाह्य service शिवाय self-hosted git remote वर संपूर्ण रचना कशी तयार करावी हे स्पष्ट करतो.

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

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

Claude Code स्किल्स तीन ठिकाणांहून लोड करते. स्किल्सचे दस्तऐवजीकरण प्रत्येक 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 जिथे enabled असेल तिथे ते लोड होते.

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

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 नवीन आहे, याची कोणतीही नोंद नसते. हे तर्कसंगत आहे, कारण स्किल हे package नसून document आहे. मात्र याचा अर्थ versioning file भोवतालच्या layer कडून करावे लागते. ती layer व्यवस्थापित करणे हे तुमचे काम आहे.

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

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

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

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

टीम कौशल्ये एकाच ठिकाणी ठेवत असली, तरी ती सामायिक करण्याची नेहमीची पद्धत म्हणजे कॉपी करण्याची पायरी: सेटअप स्क्रिप्ट, onboarding दस्तऐवजातील curl ओळ किंवा फोल्डर समक्रमित करणारा shell alias. या सर्व पद्धती सध्या branch च्या head वर असलेली आवृत्ती install करतात.

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

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

skill साठी compiler नसतो. ते model साठी दिलेल्या सूचनांचा संच असतो. त्यामुळे file byte by byte तशीच राहिली तरी skill काम करणे थांबवू शकते. model upgrade मुळे दीर्घ सूचनांचे पालन कितपत केले जाते ते बदलते. 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 रचना ओळखते. npx skills add <repo> install करते, npx skills update upgrade करते आणि npx skills list तुमच्याकडे काय install आहे ते दाखवते. Install केलेल्या गोष्टींची नोंद प्रत्येक repository साठी स्वतंत्र ठेवण्याऐवजी प्रत्येक user साठी एकदाच ठेवली जाते. त्या project मधील open request, म्हणजे issue 283, lock file मधील नोंदीनुसार सर्व tracked skills पुन्हा install करणाऱ्या skills install command ची मागणी करते, जेणेकरून दुसऱ्या machine वर तोच संच मिळेल. त्या request कडे सद्यस्थितीचा अहवाल म्हणून पाहा. Lockfile ची संकल्पना निश्चित झाली आहे. तिचा per-project भाग अजून विकसित केला जात आहे.

Specs and tests. SkillSpec याच्या उलट दृष्टिकोनातून काम करते. ती SKILL.md वर विश्वास ठेवण्याऐवजी तपासता येणारा contract मानते. तिचे घोषित उद्दिष्ट skills "followable, testable, and provable" करणे आहे. Agent कोणत्या ठिकाणी संदर्भाचा धागा गमावण्याची शक्यता आहे हे skillspec doctor <path> दाखवते. Skill कोणत्या गोष्टींना access करू शकते हे skillspec boundary map <path> दाखवते आणि त्या निष्कर्षांना जोखमीनुसार क्रम skillspec boundary assess <path> देते. हे 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 प्रक्रियेत अनपेक्षित version बदल होत नाहीत. skillspec --version ने 0.2.2 दाखवले पाहिजे. वेगळी संख्या दिसल्यास तुमच्या PATH मधील आधीची जुनी binary वापरली जात आहे.

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

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

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

1. सत्याचा एकमेव स्रोत. Skill चे नेमके एकच स्थान असते. प्रत्येक repository मध्ये प्रत ठेवण्याऐवजी ती repository त्या स्थानाचा संदर्भ घेते.
2. प्रत्येक repository साठी निश्चित केलेली आवृत्ती. प्रत्येक project वापरत असलेली अचूक revision नोंदवतो. त्यामुळे upgrade म्हणजे त्या project मधील author आणि date असलेला commit ठरतो.
3. प्रत्येक skill साठी smoke test. एक runnable check skill ने अपेक्षित result अजूनही निर्माण केला आहे, हे सिद्ध करतो.
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 असतात. हा बदल का हवा आहे, हे consumer ला समजेल अशा कारणाने message लिहा:

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 सह Pin करणे

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 प्रमाणे load होते, मात्र तिचे bytes तुम्ही निवडलेल्या commit वरील submodule मध्ये असतात.

Pin तपासा:

git submodule status

योग्य line ची सुरुवात एका space ने होते. त्यानंतर commit, path आणि सर्वात जवळचा tag येतो:

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

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

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 line हा review path आहे. प्रत्येक 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 मध्येच असतो.

त्यानंतर प्रत्येक consuming 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 वरून हे manually करण्यास सांगण्याची गरज न पडता plugin त्यांच्यासाठी enable केला जातो. त्यानंतर skills /team-skills:api-review ला प्रतिसाद देतात. याचे कारण plugin skills plugin name नुसार namespaced असतात आणि त्याच नावाच्या project skill सोबत त्यांचा conflict होऊ शकत नाही. नवीन tag push केल्यानंतर consumers /plugin marketplace update acme-agents वापरून refresh करतात. त्यानंतर install summary मध्ये तसे सांगितले असल्यास /reload-plugins चालवतात.

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

Smoke test म्हणजे ज्ञात दोष असलेल्या fixture विरुद्ध चालवलेला scripted agent run आणि त्यावरील एक assertion. Claude Code -p वापरून non-interactively चालते. 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 आहे. 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 आणि ती ज्या machine वर चालते तेथील CLAUDE.md यांचा समावेश असतो. त्यामुळे सहकाऱ्याच्या वैयक्तिक configuration मुळे result बदलू शकतो. 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 शांतपणे दुर्लक्षित करत आहे असे दिसू शकते.

Shared skill म्हणजे executable instruction

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

पहिले, SKILL.md मॉडेल काहीही वाचण्यापूर्वी shell commands चालवू शकतो. मजकुराच्या body मध्ये अशी ओळ preprocessing करते:

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

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

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

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

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

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

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

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

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

कोणीही skill संपादित केलेले नसतानाही तिच्या अंतर्गत अनेक गोष्टी बदलू शकतात. मॉडेलच्या अपग्रेडमुळे मोठ्या सूचनांचे पालन किती विश्वासार्हपणे होते हे बदलते. त्यामुळे मॉडेलने नवव्या पायरीपर्यंत पोहोचण्यावर अवलंबून असलेली skill तिथपर्यंत पोहोचणे थांबवू शकते. कमांड-लाइन साधनातील flag चे नाव बदलते. त्यामुळे agent जुना flag वापरतो, error वाचतो आणि स्वतःहून दुसरी पद्धत वापरतो. संदर्भित URL 404 प्रतिसाद देऊ लागतो. Agent harness skills निवडण्याची पद्धत बदलतो. त्यामुळे पूर्वी match जिंकणारा description आता जिंकत नाही.

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

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

FAQ

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

skill स्वतंत्र git repository मध्ये ठेवा, त्यामध्ये releases ला tags द्या आणि प्रत्येक वापरणाऱ्या project ने file copy करण्याऐवजी tag ला reference करावा. यासाठी दोन पद्धती वापरता येतात. git submodule मध्ये exact commit नोंदवला जातो आणि .claude/skills/<name> मधून submodule कडे असलेली symlink त्याला सामान्य 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 रचनेनुसार exact commit वर pin करतो. Claude Code plugin marketplace मध्ये plugin source branch किंवा tag साठी ref आणि exact commit साठी sha स्वीकारतो. दोन्ही उपस्थित असल्यास sha ला प्राधान्य मिळते. Marketplace source स्वतः केवळ ref स्वीकारतो. Commit pin वापरणे श्रेयस्कर आहे, कारण तुम्ही review केल्यानंतर tag बदलला जाऊ शकतो.

skill च्या smoke test मध्ये कोणत्या बाबी तपासाव्यात?

स्थिर बाबी तपासा. ज्ञात fault असलेल्या fixture वर skill non-interactively चालवा. त्यानंतर output मध्ये विशिष्ट identifier दिसतो का ते तपासा. उदाहरणार्थ, skill ने report करायचा असलेला rule id तपासा. --output-format json आणि --json-schema वापरून structured output मागितल्यास check अचूक होते. मूल्य न मिळाल्यास 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 ऐवजी exact 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 इतर ठिकाणी दुर्लक्षित किंवा नाकारले जाऊ शकतात. त्यामुळे व्यापकपणे share करायच्या skill मध्ये ती वापरू नका.