SSD Nodes Learn Hosting plans →
మార్గదర్శకాలు Matt Connorద్వారా Matt Connor · అప్‌డేట్ చేయబడింది 2026-08-31

రెపోల మధ్య agent skills ను drift లేకుండా పంచుకోవడం

ఎనిమిది రెపోల్లో skill కాపీలు వేర్వేరు కావడం ఆపండి. ఒక shared repo, ప్రతి project కు pinned version, smoke tests, review విధానాన్ని ఏర్పాటు చేయండి.

రెపోల మధ్య agent skills ను ఎలా పంచుకోవాలి

రెపోల మధ్య agent skills ను పంచుకోవడానికి ఫైల్‌ను కాపీ చేయడం ఆపి, దానిపై dependency గా ఆధారపడటం ప్రారంభించండి. ఒక skills repository ను నిర్వహించి, దానికి tag ఇవ్వండి. ప్రతి project ఆ tag ను pin చేయాలి. తరువాత ప్రతి skill కు ఒక smoke test జోడించండి. ప్రతి bump ను dependency bump ను review చేసిన విధంగానే review చేయండి.

దీనిలో నాలుగు భాగాలు ఉన్నాయి: ఒక shared source of truth, ప్రతి repository కు pinned version, ప్రతి skill కు ఒక smoke test, మరియు ఒక review path. ఈ భాగాలు ఎందుకు అవసరమో, 2026లో ship అయ్యే tools వాటిని ఎలా నిర్వహిస్తాయో, బయట service ఏదీ లేకుండా self-hosted git remote పై మొత్తం వ్యవస్థను ఎలా నిర్మించాలో దిగువ వివరించబడింది.

agent skill అనేది SKILL.md ఫైల్‌ను, అలాగే దానికి అవసరమైన scripts మరియు reference files ను కలిగి ఉన్న folder. ఈ unit కొత్తదైతే ముందుగా agent skill అంటే ఏమిటి, SKILL.md ఎలా పనిచేస్తుంది చదవండి. ఈ పేజీ ఆ unit చుట్టూ ఉన్న supply chain గురించి.

ఒక skill ఎక్కడ ఉంటుంది, దాన్ని పంచుకోవడం ఎందుకు కష్టం

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 చేసిన ప్రతిచోట ఇది లోడ్ అవుతుంది.

టీమ్‌కు మధ్యదే ఉపయోగకరమైనది. ఎందుకంటే అది repository లో 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 లేదు. ఏ copy కొత్తదో file లోపల నమోదు కాదు. ఇది సమంజసమే, ఎందుకంటే skill అనేది package కాకుండా document. అయితే versioning file చుట్టూ ఉన్న layer నుంచి రావాలి. ఆ layer ను మీరు నిర్వహించాలి.

సమస్య ఒకటి: నిశ్శబ్దంగా భిన్నంగా మారే ఎనిమిది కాపీలు

మొదటి రోజున copy-paste పనిచేస్తుంది. అరవయ్యవ రోజున అది విఫలమవుతుంది. ఎవరో payments repo లోని తప్పు సూచనను సరిచేస్తారు, కానీ మిగిలిన ఏడింటిని మార్చరు. మరొకరు orders లో pagination గురించి ఒక నియమాన్ని జోడిస్తారు. ఇప్పుడు agent ప్రారంభమైన directory ఆధారంగా, అదే skill పేరు రెండు భిన్నమైన reviews ను ఇస్తుంది. ఈ విషయం ఏ developer కు తెలియదు.

ఇక్కడ error state ఏదీ లేకపోవడం వల్ల ఈ వైఫల్యం నిశ్శబ్దంగా జరుగుతుంది. skill అనేది prose. పాత సూచన నమ్మకంగా కనిపించే తప్పు సమాధానాన్ని ఉత్పత్తి చేస్తుంది. ఇదే అత్యంత ఖరీదైన రకం. మీ కాపీని ఇతరుల కాపీలతో agent పోల్చదు. అందువల్ల రెండు repos మధ్య తేడాను ఒక వ్యక్తి గమనించడమే ఏకైక సంకేతం.

సమస్య రెండు: ఏదీ ఒక version ను నిర్దిష్టంగా pin చేయదు

ఒక బృందం skills ను ఒకే చోట నిర్వహించినప్పటికీ, సాధారణ sharing పద్ధతి copy దశపైనే ఆధారపడుతుంది: setup script, onboarding doc లోని ఒక curl line, లేదా folder ను sync చేసే shell alias. ఇవన్నీ ఆ సమయంలో branch head వద్ద ఉన్నదానినే install చేస్తాయి.

దీని వల్ల ఒకే application లోని ఒకే commit పై ఇద్దరు developers పనిచేస్తున్నప్పటికీ, వారు వేర్వేరు instructions ను అమలు చేయవచ్చు. కారణం, వారు sync ను వేర్వేరు రోజుల్లో నిర్వహించారు. అలాగే, agent అమలు విఫలమైన తర్వాత ముఖ్యమైన ప్రశ్నకు మీరు సమాధానం ఇవ్వలేరు: దీన్ని ఏ version లోని skill ఉత్పత్తి చేసింది? Recorded revision లేకపోతే ఆ run ను మళ్లీ పునరుత్పత్తి చేయలేం. అందువల్ల bug report పై చర్య తీసుకోవడం సాధ్యం కాదు.

సమస్య మూడు: నైపుణ్యం ఇప్పటికీ పనిచేస్తుందో ఎవరికీ తెలియదు

ఒక skill కు compiler ఉండదు. అది model కు ఇచ్చే సూచనల సమాహారం మాత్రమే. అందువల్ల ఫైలు byte for byte ఒకేలా ఉన్నప్పటికీ అది పనిచేయడం ఆపివేయవచ్చు. Model upgrade వల్ల దీర్ఘమైన instruction ను ఎంతవరకు అనుసరిస్తుందో మారవచ్చు. Skill ఉపయోగించే command line tool ఒక flag పేరు మార్చవచ్చు. Reference file లోని URL 404 status ను ఇవ్వడం ప్రారంభిస్తే, agent ఆ error page ఆధారంగా పనిచేయవచ్చు.

ఈ పరిస్థితుల్లో ఏదీ స్పష్టమైన వైఫల్యాన్ని చూపదు. Agent ఇప్పటికీ సమాధానం ఇస్తుంది. అయితే ఆ సమాధానం గత నెలతో పోలిస్తే కేవలం నాణ్యతలో తగ్గిపోయి ఉంటుంది. ప్రతి pull request ను విడిగా పరిశీలించినప్పుడు ఈ మార్పును గుర్తించడం కష్టం.

2026లో విడుదలవుతున్న సాధనాలు పరిష్కరిస్తున్న సమస్యలు

Lockfiles. Vercel Labs కు చెందిన skills command line tool (vercel-labs/skills, MIT licensed, 5 August 2026 నాటికి v1.5.22) git repository నుంచి skills ను మీ agent ఆశించే directory లో install చేస్తుంది. ఇది డెబ్బైకి పైగా agents కోసం directory layout ను గుర్తిస్తుంది. npx skills add <repo> install చేస్తుంది, npx skills update upgrade చేస్తుంది, npx skills list మీ వద్ద ఉన్నవాటిని చూపిస్తుంది. Install చేసిన వాటి record ప్రతి repositoryకి ఒకసారి కాకుండా ప్రతి userకి ఒకసారి ఉంచబడుతుంది. అదే project లోని open request (issue 283), lock fileలో track చేసిన ప్రతి skill ను మళ్లీ install చేసే skills install command ను కోరుతోంది. దీని ద్వారా రెండో machineలో కూడా అదే set లభిస్తుంది. ఆ request ను ప్రస్తుత స్థితి నివేదికగా పరిగణించండి. Lockfile విధానం ఖరారైంది. అయితే, దాని per-project భాగం ఇంకా అభివృద్ధిలో ఉంది.

Specs and tests. SkillSpec మరో దృక్కోణాన్ని అనుసరిస్తుంది. ఇది SKILL.md ను నమ్మాల్సిన proseగా కాకుండా తనిఖీ చేయాల్సిన contractగా పరిగణిస్తుంది. Skills ను "followable, testable, and provable" చేయడం దీని ప్రకటిత లక్ష్యం. skillspec doctor <path> agent thread ను ఎక్కడ కోల్పోయే అవకాశం ఉందో నివేదిస్తుంది. skillspec boundary map <path> skill ఏ వనరులను చేరుకోగలదో నివేదిస్తుంది. skillspec boundary assess <path> ఆ ఫలితాలను risk ఆధారంగా rank చేస్తుంది. ఇది Rust crate. దీనికి MIT లేదా Apache 2.0 dual license ఉంది. 29 July 2026 నాటికి దీని version 0.2.2. తాజా versionకు బదులుగా నిర్దిష్ట versionను install చేయండి:

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

--locked crate ప్రచురించినప్పుడు ఉపయోగించిన dependency versionsతో build చేస్తుంది. అందువల్ల build మీకు తెలియకుండా మారదు. skillspec --version తప్పనిసరిగా 0.2.2 ను print చేయాలి. వేరే number కనిపిస్తే, మీ PATH లో ముందుగా ఉన్న పాత binary అమలవుతోందని అర్థం.

Vendor practice. google/skillsలో skills ను ఎలా build చేస్తుందో Google, how it builds, tests and scales agent skills అనే postలో వివరించింది. పెద్ద స్థాయిని పక్కన పెడితే, విధానం సాధారణ continuous integration (CI). Merge చేయడానికి ముందు ప్రతి skill frontmatter metadata, line count, directory layout, naming కోసం linters ను pass చేయాలి. 404ను return చేసే ఏ URL అయినా link checker buildను fail చేస్తుంది. దీని ద్వారా agent ఊహించి సృష్టించినట్లు కనిపించే సరైన link కూడా గుర్తించబడుతుంది. Skillతో పాటు evaluation prompt suite మరియు scoring rubricను authors అందించాలి. తరువాత scheduled evaluation jobs ప్రతి వారం మొత్తం libraryపై అమలై regressions ను గుర్తిస్తాయి. ప్రతి skillకు ఒక named owner ఉంటారు. Quality తగ్గినప్పుడు ఆ owner దాన్ని సరిచేయాలి.

మూడు సమాధానాల వెనుక ఉన్న నమూనా

మీరు వాటిలో ఏదో ఒకదాన్ని ఎంచుకోవాల్సిన అవసరం లేదు. వాటి వెనుక ఒకే నిర్మాణం ఉంది. plain git మీకు దాని మొత్తాన్ని అందిస్తుంది.

  1. ఒకే నిజమైన మూలం. ప్రతి skill కు ఖచ్చితంగా ఒకే స్థానం ఉంటుంది. ప్రతి repository కాపీని ఉంచకుండా ఆ స్థానాన్నే సూచిస్తుంది.
  2. ప్రతి repository కు స్థిరపరచిన version. ప్రతి project తాను ఉపయోగించే ఖచ్చితమైన revision ను నమోదు చేస్తుంది. అందువల్ల upgrade అనేది author మరియు date ఉన్న ఆ project లోని ఒక commit అవుతుంది.
  3. ప్రతి skill కు smoke test. skill వాగ్దానం చేసిన ఫలితాన్ని ఇప్పటికీ ఇస్తోందని నిర్ధారించే ఒక runnable check ఉంటుంది.
  4. ఒక review మార్గం. shared skill లో మార్పు review ద్వారా వెళ్తుంది. దాన్ని స్వీకరించే ముందు ప్రతి consumer diff ను చూస్తుంది.

అదే dependency యొక్క నిర్మాణం. tooling దాని చుట్టూ అభివృద్ధి చెందకముందే skills shared artifact గా మారాయి. అందువల్ల మీరు ఇప్పటికే విశ్వసించే tooling ను ఉపయోగించడం అత్యంత సురక్షితమైన ఎంపిక.

స్వయంగా నిర్వహించే git remote పై చిన్న బృందం కోసం ఒక నిర్మాణం

ఒక repository లో skills మాత్రమే ఉంటాయి. అందులో మరే ఇతర కంటెంట్ ఉండదు. అందువల్ల దాని history సూచనల 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తో commit ను స్థిరపరచడం

ఒక submodule మీ repository లోపల మరొక repository యొక్క ఒక నిర్దిష్ట commit ను నమోదు చేస్తుంది. ఆ నమోదు చేసిన commit నే pin అంటారు. ప్రతి వినియోగించే 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, disk పై మరెక్కడైనా ఉన్న directory కు symlink అయి ఉండవచ్చు. Claude Code ఆ symlink ను అనుసరించి target నుంచి SKILL.md ను చదువుతుంది. అందువల్ల skill సాధారణ project skill లా load అవుతుంది, కానీ దాని ఫైళ్లు మీరు ఎంచుకున్న commit వద్ద ఉన్న submodule లో ఉంటాయి.

Pin ను తనిఖీ చేయండి:

git submodule status

సరైన line లో మొదట ఒక ఖాళీ ఉంటుంది. తరువాత 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 ను నడుపుతున్నారు. కొత్త clone లకు git clone --recurse-submodules అవసరం. ఆ line README లో ఉండాలి, ఎందుకంటే సాధారణ 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 కు ఉపయోగపడుతుంది. ప్రతి ఇతర consuming repo లో కనిపించే అదే మార్పును ఇది చూపిస్తుంది. అలాగే దీన్ని pull request లో చేర్చడం సులభం.

దీనికి బదులుగా plugin marketplace తో pinning

ప్రతి developer submodules నేర్చుకోవాలని మీరు కోరుకోకపోతే, Claude Code plugin system distribution ను మీ తరఫున నిర్వహిస్తుంది. ఇది 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 చేయాలో సూచించే source. ఇది branch లేదా tag కోసం ref ను అంగీకరిస్తుంది. ఇది sha ను అంగీకరించదు. Catalog లోని plugin source మాత్రం రెండింటినీ అంగీకరిస్తుంది. రెండూ set చేసినప్పుడు sha effective pin అవుతుంది. అందువల్ల exact-commit pin catalog entry లో ఉండాలి.

ప్రతి వినియోగించే repository తన committed .claude/settings.json లో marketplace ను declare చేస్తుంది:

{
  "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 చేయమని prompt కనిపిస్తుంది. Wiki page లో దాని కోసం ప్రత్యేక సూచనలు ఇవ్వకుండానే plugin వారికి enable అవుతుంది. ఆ తరువాత skills /team-skills:api-review కు స్పందిస్తాయి. ఎందుకంటే plugin పేరు ఆధారంగా plugin skills కు namespace ఉంటుంది. అందువల్ల అదే పేరున్న project skill తో collision జరగదు. మీరు కొత్త tag push చేసిన తరువాత, వినియోగదారులు /plugin marketplace update acme-agents తో refresh చేయాలి. Install summary అలా అడిగితే తరువాత /reload-plugins ను run చేయాలి.

ఒక skill కోసం smoke test రాయడం

Smoke test అనేది తెలిసిన లోపం ఉన్న fixture పై scripted agent run చేయడం, అలాగే ఒక assertion చేయడం. Claude Code ను -p తో non-interactive విధంగా నడపవచ్చు. User-invoked skill అక్కడ కూడా పనిచేస్తుంది: prompt string లో /skill-name ను ఉంచితే run ప్రారంభమయ్యే ముందు అది expand అవుతుంది.

#!/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 ఒక deliberate fault ఉన్న చిన్న file. Skill ఆ fault ను పేరుతో గుర్తించాలి అనేదే assertion. Filter ఉత్పత్తి చేసే ఫలితం null అయితే jq -e non-zero తో exit అవుతుంది. అందువల్ల seeded fault ను skill ఇకపై గుర్తించకపోతే script విఫలమవుతుంది. Run విఫలమైతే claude స్వయంగా non-zero తో exit అవుతుంది. ఈ రెండు వైఫల్యాల్లో ఏదైనా failed test గా మార్చేది set -euo pipefail.

Runs మధ్య model తన సమాధానాలను వేరే విధంగా రాయవచ్చు. అందువల్ల పూర్తి sentence పై ఎప్పుడూ assert చేయవద్దు. Skill తప్పనిసరిగా output చేయాల్సిన identifier పై లేదా మీరు కోరిన schema లోని field పై assert చేయండి. Run తక్కువ ఖర్చుతో ఉండేందుకు fixture ను చిన్నదిగా ఉంచండి.

CIలో --bare జోడించండి. అది లేకపోతే interactive session ఉపయోగించే అదే context ను claude -p load చేస్తుంది. ఇందులో hooks, plugins, అలాగే run అవుతున్న machine నుంచి వచ్చే CLAUDE.md కూడా ఉంటాయి. అందువల్ల teammate యొక్క వ్యక్తిగత configuration ఫలితాన్ని మార్చవచ్చు. Bare mode అన్ని auto-discoveryలను దాటవేస్తుంది. కాబట్టి మీరు పరీక్షిస్తున్న skill కూడా load కాదు. ఆ 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 ను fail చేయండి. ఉనికిలో లేని revision ను సూచించే pin ను ఇది గుర్తిస్తుంది. లేకపోతే agent మీ house rules ను మౌనంగా పట్టించుకోకపోవడం లాగా కనిపిస్తుంది.

షేర్ చేసిన skill అనేది అమలు చేయగల సూచన

ఈ పదబంధం అక్షరార్థంగా వర్తించేలా చేసే రెండు లక్షణాలు ఉన్నాయి. ఫైల్ మరొక బృందం నుంచి వచ్చినప్పుడు రెండూ ముఖ్యమైనవే.

మొదటిది, మోడల్ ఏదైనా చదవకముందే ఒక SKILL.md shell commands ను అమలు చేయగలదు. bodyలోని ఇలాంటి line preprocessing ను సూచిస్తుంది:

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

ఈ command skill ను load చేస్తున్న machine పై అమలవుతుంది. దాని output మోడల్ స్వీకరించే textలో placeholder స్థానాన్ని భర్తీ చేస్తుంది. మూడు backticks తరువాత ! తో ప్రారంభమైన fenced block కూడా ఇదే విధంగా అనేక commands ను అమలు చేస్తుంది. runtimeలో వీటిలో దేనికీ ఎవరూ approval ఇవ్వరు. Shared 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 ను review చేయాలి, ఎందుకంటే ఒక skill తనకు విస్తృతమైన tool access ను తానే మంజూరు చేసుకోగలదు.

కాబట్టి skill bump ను dependency bump లాగే పరిగణించండి. mechanism అనుమతించే చోట exact commit తో pin చేయండి, ఎందుకంటే tag ను మార్చవచ్చు; branch అయితే నిర్వచనం ప్రకారమే మారుతుంది. Lockdown చేసిన machineలో settingsలోని "disableSkillShellExecution": true ప్రతి command substitution ను అమలు చేయకుండా, literal text [shell command execution disabled by policy] తో భర్తీ చేస్తుంది. Managed settings ద్వారా ఇది అమలైతే user దాన్ని override చేయలేరు. Bundled మరియు managed skills కు ఈ setting వర్తించదు.

Skill ఏ data ను చదువుతుందో కూడా ఇదే జాగ్రత్తతో పరిశీలించాలి. env ను అమలు చేసే లేదా config file ను తెరిచే skill, దానిలో దొరికినదంతా model context లోకి తీసుకువస్తుంది. మీరు అమలు చేసే agents నుండి secrets ను బయట ఉంచడం లో వివరించిన వైఫల్యం ఇదే. Page ను fetch చేసే లేదా query ను అమలు చేసే skill కూడా ఇదే exposure ను బయటికి మళ్లిస్తుంది. Retrieved text contextలోకి వచ్చేటప్పుడు, మీరు రాసిన instructions లాగే కనిపిస్తుంది. అందువల్ల web search కోసం agent ను మీ స్వంత SearXNG instance వైపు మళ్లించే ముందు ఈ boundary గురించి చదవాలి.

వెర్షన్ bump సమయంలో చదవాల్సినవి

  • ప్రతి SKILL.md body యొక్క diff, ఎందుకంటే మీ agent అనుసరించే సూచన అదే.
  • ప్రతి command substitution, ఎందుకంటే skill load అయినప్పుడు అవి మీ machine పై అమలవుతాయి.
  • allowed-tools లోని ఏ మార్పైనా, ఎందుకంటే ఆ line prompt లేకుండానే tools ను అనుమతిస్తుంది.
  • tag వెనుక జరిగిన test run. Shared repository CIలో స్వంత smoke tests అమలు చేస్తే, మీరు pin చేస్తున్న tag కు green run జతచేయబడి ఉండాలి.

పది నిమిషాల్లో మొత్తం diff చదవలేని reviewer, అతిగా పెరిగిన skill ను పరిశీలిస్తున్నాడు. దాన్ని విడగొట్టండి. మీ agents చదివే repository documents కు కూడా ఇదే వర్తిస్తుంది: శాశ్వత నియమాలను AGENTS.md మరియు HUMAN.md విభజనలో వివరించిన files లో ఉంచండి, architectural reasoning ను agents కోసం రాసిన DESIGN.md లో ఉంచండి, skills ను పరిమిత విధానాలుగానే ఉంచండి.

మోడల్ లేదా tool మార్పు వల్ల skill పనిచేయకపోతే

ఎవరూ skill ను సవరించకపోయినా, దాని అంతర్గత ఆధారాలలో అనేక మార్పులు జరగవచ్చు. Model upgrade వల్ల దీర్ఘ instruction ను ఎంత విశ్వసనీయంగా అనుసరిస్తుందో మారుతుంది. అందువల్ల model తొమ్మిదో దశకు చేరుకోవడంపై ఆధారపడిన skill, ఆ దశకు చేరుకోకుండా ఆగిపోవచ్చు. Command line tool ఒక flag పేరు మార్చవచ్చు. అప్పుడు agent పాత flag ను అమలు చేసి, error ను చదివి, తనంతట తానే పరిష్కారం ఊహించవచ్చు. Referenced URL 404 తిరిగి ఇవ్వడం ప్రారంభించవచ్చు. Agent harness skills ను ఎంచుకునే విధానం మారవచ్చు. దాంతో గతంలో match లో గెలిచిన description ఇప్పుడు గెలవకపోవచ్చు. Procedure ఇలా మధ్యలోనే ముగియడం ప్రారంభమైనప్పుడు version bump చేయడం వల్ల సమస్య పరిష్కారం కాదు. చివరి దశలు తప్పనిసరిగా అమలయ్యేలా instructions కు నిర్మాణం అవసరం. the unlazy skill and its Depth Tree method వెనుక ఉన్న విధానం ఇదే.

అందుకే ఈ అమరికలో smoke test కీలక పాత్ర పోషిస్తుంది. ప్రతి skill యొక్క test ను push సమయంలోనే కాకుండా, నిర్దిష్ట schedule ప్రకారం కూడా అమలు చేయండి. ఈ కారణంగానే Google తన evaluation jobs ను మొత్తం library పై వారానికి ఒకసారి అమలు చేస్తుంది. పది skills ఉన్న team కు చిన్న VPS పై వారానికి ఒకసారి నడిచే cron job సరిపోతుంది. Developer గుర్తించేలోపు సమస్య గురించి తెలుసుకునే ఏకైక మార్గం ఇదే.

Portability కూడా సహాయపడుతుంది. Agent Skills spec frontmatter ను ఆరు keys కు పరిమితం చేస్తుంది. అందువల్ల ఆ spec కు అనుగుణంగా రాసిన skill, దాన్ని రాసిన tool మాత్రమే కాకుండా ఇతర tools లో కూడా load అవుతుంది. మీరు చేర్చే ప్రతి harness-specific key ఒక vendor పై చేసే పందెం వంటిది. Model మారినప్పటికీ పనిచేసే skills రాయడం ప్రత్యేకమైన పద్ధతి. దీని గురించి making a skill work on any model లో వివరించబడింది.

FAQ

అనేక repositories మధ్య ఒకే agent skill ను ఎలా పంచుకోవాలి?

skill ను ప్రత్యేక git repository లో ఉంచి, అందులో releases కు tags సృష్టించండి. ప్రతి వినియోగించే project ఫైల్‌ను copy చేయకుండా ఒక tag ను reference చేయాలి. దీనికి రెండు విధానాలు ఉన్నాయి. git submodule ఖచ్చితమైన commit ను నమోదు చేస్తుంది. .claude/skills/<name> నుంచి submodule కు ఉన్న symlink దాన్ని సాధారణ project skill గా load అయ్యేలా చేస్తుంది. plugin marketplace /plugin ద్వారా ఇదే పనిని చేస్తుంది. వినియోగించే repository లోని .claude/settings.json లో pin ప్రకటించబడుతుంది. ఈ రెండు విధానాలు version ను git history లో ఉంచుతాయి. అందువల్ల నిర్దిష్ట agent run కు ఏ instructions కారణమయ్యాయో తెలుసుకోవచ్చు.

agent skill ను నిర్దిష్ట version కు pin చేయవచ్చా?

SKILL.md లోపల నుంచి చేయలేరు. ఆ frontmatter లో version key లేదు. ఈ pin ఫైల్ చుట్టూ ఉన్న 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 ఏమి నిర్ధారించాలి?

మార్పులకు తక్కువగా లోనయ్యే అంశాన్ని నిర్ధారించండి. తెలిసిన fault ఉన్న fixture పై skill ను non-interactive గా run చేయండి. తరువాత output లో నిర్దిష్ట identifier కనిపిస్తుందో చూడండి. ఉదాహరణకు, skill report చేయాల్సిన rule id ను పరిశీలించవచ్చు. --output-format json మరియు --json-schema తో structured output కోరితే check ఖచ్చితంగా ఉంటుంది. విలువ కనిపించకపోతే jq -e script ను fail చేస్తుంది. పూర్తి sentence పై ఎప్పుడూ assert చేయవద్దు. runs మధ్య model తన సమాధానాలను వేరే విధంగా రాయవచ్చు.

మరొక team repository నుంచి shared skill ను install చేయడం సురక్షితమేనా?

దాన్ని code dependency గా పరిగణించండి. ఎందుకంటే అది అమలు చేయగల instruction. ఒక SKILL.md load సమయంలో ! command substitution రూపం ద్వారా shell commands ను run చేయగలదు. frontmatter లోని allowed-tools field prompt లేకుండానే tools కు ముందస్తు అనుమతి ఇవ్వగలదు. ప్రతి bump సమయంలో diff ను పరిశీలించండి. branch కు బదులుగా ఖచ్చితమైన commit కు pin చేయండి. మీ స్వంత team నియంత్రించే source కు ప్రాధాన్యం ఇవ్వండి. Managed machines లో settings లోని "disableSkillShellExecution": true command substitutions పూర్తిగా run కాకుండా ఆపుతుంది.

Claude Code కాకుండా ఇతర agents లో shared skill పనిచేస్తుందా?

మీరు ఉపయోగించే frontmatter పై ఇది ఆధారపడి ఉంటుంది. Agent Skills spec ఆరు keys ను నిర్వచిస్తుంది: name, description, license, compatibility, metadata మరియు allowed-tools. ఆ keys కు మాత్రమే పరిమితమైన skill, ఈ spec ను అమలు చేసే tools అంతటా load అవుతుంది. మార్పులు లేకుండానే అది Claude Code లో కూడా load అవుతుంది. Harness-specific keys మరియు spec కు మించిన body features ఇతర చోట్ల విస్మరించబడవచ్చు లేదా తిరస్కరించబడవచ్చు. అందువల్ల విస్తృతంగా share చేయాలనుకునే skill లో వాటిని చేర్చవద్దు.

#agent-skills#versioning#claude-code#team-standards#self-hosting