SSD Nodes Learn 🎉 VPS $5.50/నెల నుండి
మార్గదర్శకాలు Matt Connorద్వారా Matt Connor · అప్‌డేట్ చేయబడింది 2026-08-13

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

ఎనిమిది reposలో skill కాపీలు కాలక్రమేణా మారిపోతాయి. ఒక shared repositoryని source of truthగా ఉంచి, ప్రతి project tag versionను pin చేసి review చేసే విధానాన్ని తెలుసుకోండి.

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

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

దీనిలో నాలుగు భాగాలు ఉన్నాయి: భాగస్వామ్య source of truth, ప్రతి repository కు pinned version, ప్రతి skill కు smoke test, మరియు review path. ప్రతి భాగం ఎందుకు అవసరమో, 2026లో విడుదలైన 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 enabled ఉన్న ప్రతి చోట ఇది లోడ్ అవుతుంది.

బృందానికి మధ్యలో ఉన్న ఎంపిక ఉపయోగకరమైనది. ఇది repository లో commit చేయబడుతుంది. అందువల్ల repo ను 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 ను మీరు నిర్వహించాలి.

సమస్య 1: నిశ్శబ్దంగా వేరుపడే ఎనిమిది కాపీలు

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

లోపం నిశ్శబ్దంగానే ఉంటుంది, ఎందుకంటే error state ఉండదు. Skill అనేది prose. పాత instruction వల్ల agent నమ్మకంగా, కానీ తప్పుగా సమాధానం ఇస్తుంది. ఇదే ఎక్కువ ఖర్చు కలిగించే రకం. మీ కాపీని ఇతరుల కాపీలతో agent పోల్చదు. అందువల్ల రెండు repos లో తేడా ఉందని ఒక వ్యక్తి గుర్తించడం మాత్రమే signal.

సమస్య 2: ఏదీ version ను pin చేయదు

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

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

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

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

ఈ సందర్భాల్లో ఏదీ స్పష్టమైన failure గా కనిపించదు. agent ఇప్పటికీ సమాధానం ఇస్తుంది. కానీ ఆ సమాధానం గత నెలతో పోలిస్తే నాసిరకంగా ఉంటుంది. ప్రతి pull request లో కొద్దికొద్దిగా జరిగే ఈ మార్పును గుర్తించడం కష్టం.

2026లో అందుబాటులోకి వచ్చిన సాధనాలు పరిష్కరించేవి

ఇప్పుడు అనేక పరిష్కారాలు అందుబాటులోకి వస్తున్నాయి. అయితే వెర్షన్‌ను ఎక్కడ ఉంచాలి అనే విషయంలో వాటి విధానాలు వేర్వేరుగా ఉన్నాయి.

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

Specs and tests. SkillSpec దీనికి భిన్నమైన విధానాన్ని అనుసరిస్తుంది. ఇది SKILL.md ను నమ్మాల్సిన prose గా కాకుండా తనిఖీ చేయాల్సిన contract గా పరిగణిస్తుంది. Skills ను "followable, testable, and provable" గా మార్చడం దీని ప్రకటించిన లక్ష్యం. skillspec doctor <path> agent ఎక్కడ workflow ను కోల్పోయే అవకాశం ఉందో చూపిస్తుంది. skillspec boundary map <path> skill ఏ వనరులను చేరుకోగలదో చూపిస్తుంది. skillspec boundary assess <path> ఆ ఫలితాలను risk ఆధారంగా క్రమబద్ధీకరిస్తుంది. ఇది Rust crate. దీనికి MIT లేదా Apache 2.0 అనే రెండు లైసెన్సులు ఉన్నాయి. 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 ప్రక్రియలో versions మారవు. 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 లో వివరించింది. పెద్ద స్థాయి అంశాలను పక్కన పెడితే, mechanism సాధారణ continuous integration (CI). ప్రతి skill merge కావడానికి ముందు frontmatter metadata, line count, directory layout, naming కోసం linters ను pass చేయాలి. 404 ను return చేసే ఏ URL అయినా link checker build ను fail చేస్తుంది. Agent ఊహించి రూపొందించినట్లుగా కనిపించే link లను ఇది గుర్తిస్తుంది. Authors skill తో పాటు evaluation prompt suite మరియు scoring rubric ను కూడా అందించాలి. ఆ తర్వాత scheduled evaluation jobs మొత్తం library పై ప్రతి వారం run అవుతాయి. ఇవి regressions ను గుర్తిస్తాయి. అదనంగా ప్రతి skill కు ఒక named owner ఉంటారు. Quality తగ్గినప్పుడు దాన్ని సరిచేయడం వారి బాధ్యత.

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

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

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

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

చిన్న బృందం కోసం self-hosted git remote లో లేఅవుట్

ఒక repository లో నైపుణ్యాలు ఉంటాయి. అందులో మరేమీ ఉండదు. అందువల్ల దాని 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 ను కలిగి ఉంటాయి. ఆ bump ను వినియోగదారు ఎందుకు కోరుకుంటారో 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 తో నిర్దిష్ట commit కు pin చేయడం

ఒక 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 డిస్క్‌లోని వేరే ప్రదేశంలోని directory కు symlink అయి ఉండవచ్చు. Claude Code ఆ symlink ను అనుసరించి target నుంచి SKILL.md ను చదువుతుంది. అందువల్ల skill సాధారణ project skill లా లోడ్ అవుతుంది, కానీ దాని 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 లో ఉండాలి, ఎందుకంటే సాధారణ 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 చేయాలో సూచించేది. ఇది branch లేదా tag కోసం ref ను అంగీకరిస్తుంది. అయితే sha ను అంగీకరించదు. Catalog లోని plugin source మాత్రం రెండింటినీ అంగీకరిస్తుంది. రెండూ set చేసినప్పుడు sha effective pin అవుతుంది. అందువల్ల exact-commit pin catalog entry లో ఉండాలి.

ప్రతి consuming 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 skills కు plugin name ఆధారంగా namespace ఉంటుంది. అందువల్ల అవి అదే పేరున్న project skill తో collide కావు. మీరు కొత్త tag push చేసిన తర్వాత, consumers /plugin marketplace update acme-agents తో refresh చేసి, install summary అలా అడిగితే /reload-plugins ను అమలు చేస్తారు.

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

Smoke test అనేది తెలిసిన లోపం ఉన్న fixture పై script ద్వారా agent ను నడిపించి, ఒక 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. ఆ skill ఆ లోపాన్ని పేరుతో గుర్తించాలి. దాని filter null ను ఉత్పత్తి చేసినప్పుడు jq -e non-zero తో ముగుస్తుంది. అందువల్ల ముందుగా ఉంచిన లోపాన్ని skill గుర్తించడం ఆపితే script విఫలమవుతుంది. Run విఫలమైనప్పుడు claude కూడా non-zero తో ముగుస్తుంది. ఈ రెండు వైఫల్యాల్లో ఏదైనా test విఫలమైనదిగా set -euo pipefail చూపిస్తుంది.

ఒక run నుంచి మరొక run కు model తన సమాధానాలను వేరే విధంగా రాస్తుంది. కాబట్టి పూర్తి వాక్యంపై ఎప్పుడూ assertion చేయవద్దు. Skill తప్పనిసరిగా విడుదల చేయాల్సిన identifier పై లేదా మీరు కోరిన schema లోని field పై assertion చేయండి. Run తక్కువ ఖర్చుతో పూర్తయ్యేలా fixture ను చిన్నగా ఉంచండి.

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

ఒక shared skill అమలు చేయగల instruction

ఇది అక్షరార్థంగా వర్తించేలా చేసే రెండు features ఉన్నాయి. ఆ file మరో team నుంచి వచ్చినప్పుడు రెండూ ముఖ్యమైనవే.

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

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

ఈ command skill ను load చేస్తున్న machineపై run అవుతుంది. దాని output model అందుకునే textలో placeholder స్థానాన్ని భర్తీ చేస్తుంది. మూడు backticks తర్వాత ! తో తెరిచిన fenced block కూడా అనేక commands ను ఇదే విధంగా run చేస్తుంది. Run timeలో వీటిలో దేనికీ ఎవరూ approval ఇవ్వరు. Shared skill చదవడం అంటే దానిలోని command substitutions ను చదవడమే.

రెండవది, frontmatter tools ను ముందుగానే approve చేయగలదు. 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 నిర్వచనపరంగానే మారుతూ ఉంటుంది. Lock చేసిన machineలో settingsలోని "disableSkillShellExecution": true ప్రతి command substitutionను run చేయకుండా, దాని బదులుగా literal text [shell command execution disabled by policy] తో భర్తీ చేస్తుంది. Managed settings ద్వారా అమలు చేసినప్పుడు user దాన్ని override చేయలేడు. Bundled మరియు managed skills ఈ settingకు మినహాయింపు.

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

వెర్షన్ పెంచినప్పుడు ఏమి చదవాలి

  • ప్రతి 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 జతచేయబడి ఉండాలి.

Reviewer పది నిమిషాల్లో మొత్తం diff చదవలేకపోతే, ఆ skill చాలా పెద్దదిగా పెరిగిందని అర్థం. దాన్ని విభజించండి. Agents చదివే repository documents కు కూడా ఇదే వర్తిస్తుంది: శాశ్వత నియమాలను AGENTS.md మరియు HUMAN.md విభజనలో వివరించిన ఫైళ్లలో ఉంచండి, architectural reasoning ను agents కోసం రాసిన DESIGN.mdలో ఉంచండి, skills ను పరిమిత procedures గా ఉంచండి.

ఒక model లేదా tool మార్పు skill ను విఫలం చేసినప్పుడు

ఎవరూ skill ను సవరించకపోయినా, దాని అంతర్గత ఆధారాల్లో అనేక మార్పులు జరగవచ్చు. Model upgrade వల్ల దీర్ఘమైన instruction ను ఎంత విశ్వసనీయంగా అనుసరించాలో మారుతుంది. అందువల్ల model తొమ్మిదో దశకు చేరుకోవడంపై ఆధారపడిన skill అక్కడికి చేరుకోకపోవచ్చు. Command line tool ఒక flag పేరును మార్చవచ్చు. అప్పుడు agent పాత flag ను అమలు చేసి, వచ్చిన error ను చదివి, తనంతట తానే మరో విధానాన్ని ప్రయత్నించవచ్చు. Referenced URL ఒక దశలో 404 ను తిరిగి ఇవ్వడం ప్రారంభించవచ్చు. Agent harness skills ను ఎంచుకునే విధానం మార్చవచ్చు. దాంతో ఇంతకుముందు match లో గెలిచిన description ఇప్పుడు గెలవకపోవచ్చు.

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

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

FAQ

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

ఆ skill ను ప్రత్యేక git repository లో ఉంచి, అందులో releases కు tags పెట్టండి. ప్రతి ఉపయోగించే project ఫైల్‌ను copy చేయకుండా ఒక tag ను reference చేసేలా చేయండి. ఇందుకు రెండు విధానాలు ఉన్నాయి. git submodule ఖచ్చితమైన commit ను నమోదు చేస్తుంది. .claude/skills/<name> నుండి submodule కు చేసే symbolic link దాన్ని సాధారణ project skill గా load అయ్యేలా చేస్తుంది. plugin marketplace ఇదే పనిని /plugin ద్వారా చేస్తుంది. Consuming 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 ఏ విషయాన్ని నిర్ధారించాలి?

మార్పులకు లోనుకాని విషయాన్ని నిర్ధారించండి. తెలిసిన లోపం ఉన్న fixture పై skill ను non-interactively 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 గా పరిగణించండి. ఎందుకంటే అది అమలు చేయగల instructions ను కలిగి ఉంటుంది. ఒక 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