Mga Gabay

Ni Matt Connor 2026-08-06 · Na-update 2026-08-31

Paano magbahagi ng agent skills sa iba't ibang repo

Q: Maaari ko bang i-pin ang isang agent skill sa isang partikular na bersyon?

Hindi mula sa loob ng SKILL.md, dahil walang version key ang frontmatter na iyon. Ang pin ay dapat magmula sa layer sa labas ng file. Ang git submodule ay awtomatikong nag-pi-pin ng eksaktong commit. Sa isang Claude Code plugin marketplace, ang plugin source ay tumatanggap ng ref para sa isang branch o tag at sha para sa eksaktong commit, at ang sha ang mananaig kapag parehong naroroon. Ang marketplace source mismo ay tumatanggap lamang ng ref. Mas mainam na gamitin ang commit pin, dahil ang isang tag ay maaaring ilipat matapos mo itong ma-review.

Iwasan ang code drift sa pamamagitan ng pagtrato sa agent skills bilang dependencies. Alamin kung paano i-pin ang version sa bawat repo at magpatupad ng smoke tests para rito.

Paano magbahagi ng agent skills sa iba't ibang repo

Para makapagbahagi ng agent skills sa iba't ibang repo, itigil ang pag-copy ng file at magsimulang umasa sa dependency nito. Panatilihin ang isang skills repository, lagyan ito ng tag, at hayaang mag-pin ang bawat project sa isang tag. Pagkatapos, magdagdag ng smoke test bawat skill, at i-review ang bawat bump gaya ng pag-review mo sa dependency bump.

Binubuo ito ng apat na bahagi: isang shared source of truth, isang naka-pin na bersyon bawat repository, isang smoke test bawat skill, at isang review path. Ipinapaliwanag ng lahat ng nasa ibaba kung bakit umiiral ang bawat bahagi, ano ang ginagawa ng mga tool na ilalabas sa 2026 tungkol dito, at kung paano buuin ang buong setup sa isang self-hosted git remote nang walang ibang external service.

Ang isang agent skill ay isang folder na naglalaman ng SKILL.md file, kasama ang anumang script at reference file na kailangan nito. Kung bago ang unit na ito, basahin muna ang kung ano ang agent skill at paano gumagana ang SKILL.md. Ang pahinang ito ay tungkol sa supply chain na nakapalibot sa unit na iyon.

Naglo-load ang Claude Code ng mga skill mula sa tatlong lokasyon, at nakalista ang bawat path sa skills documentation.

Ang ~/.claude/skills/<skill-name>/SKILL.md ay personal. Naglo-load ito sa lahat ng iyong mga project at hindi sa iba.
Ang .claude/skills/<skill-name>/SKILL.md ay nasa antas ng project. Naglo-load ito para sa sinumang mag-check out ng repository na iyon.
Ang <plugin>/skills/<skill-name>/SKILL.md ay kasama sa loob ng isang plugin. Naglo-load ito saanman naka-enable ang plugin na iyon.

Ang nasa gitna ang pinakagamitin para sa isang team, dahil ito ay naka-commit at makukuha ito ng lahat ng mag-clone ng repo. Dito rin nagsisimula ang problema. Ang isang skill sa .claude/skills/ ay pagmamay-ari ng isang repository. Mayroon kang walong repository. Kaya ang skill ay nakokopya nang walong beses.

Walang tulong na maibibigay ang frontmatter. Pinapayagan ng Agent Skills spec ang anim na key, at ang mga distribution path na nagpapatupad nito ay nagpi-print ng listahan kapag gumamit ka ng iba:

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

Pansinin ang wala: walang version key. Walang nakatala sa loob ng file kung aling kopya ang mas bago. Makatwiran ito, dahil ang isang skill ay isang dokumento at hindi isang package. Ibig sabihin nito, ang versioning ay dapat magmula sa layer sa paligid ng file, at ang layer na iyon ay trabaho mo.

Problema isa: walong kopya na tahimik na naghihiwalay

Gumagana ang copy-paste sa unang araw. Nabibigo ito sa ika-animnapung araw. May nag-aayos ng maling instruction sa payments repo at hindi nito ginalaw ang pito pang iba. May iba namang nagdagdag ng rule tungkol sa pagination sa orders. Ngayon, ang parehong skill name ay nagbibigay ng dalawang magkaibang review depende sa kung saang directory nagsimula ang agent, at walang alam ang mga developer.

Ang pagkabigo ay tahimik dahil walang error state. Ang isang skill ay prose. Ang lumang instruction ay nagbubunga ng kampante ngunit maling sagot, na siyang magastos na uri ng pagkakamali. Walang anuman sa agent ang nagkukumpara ng iyong kopya laban sa iba, kaya ang tanging signal ay ang mapansin ng isang tao na hindi magkatugma ang dalawang repo.

Problema dalawa: walang naka-pin na bersyon

Kahit na pinapanatili ng isang team ang mga skill sa iisang lugar, ang karaniwang paraan ng pagbabahagi ay sa pamamagitan ng pag-copy: isang setup script, isang curl line sa onboarding doc, o isang shell alias na nag-si-sync ng folder. Lahat ng ito ay nag-i-install ng kung ano man ang nasa head ng branch sa kasalukuyan.

Ibig sabihin nito, ang dalawang developer na nasa parehong commit ng parehong application ay maaaring nagpapatakbo ng magkaibang instruction, dahil nag-sync sila sa magkaibang araw. Ibig sabihin din nito, hindi mo masasagot ang tanong na mahalaga matapos ang isang bad agent run: anong bersyon ng skill ang gumawa nito? Kung walang naitalang revision, hindi ma-reproduce ang run, kaya hindi rin maaksyunan ang bug report.

Problema tatlo: walang nakakaalam kung gumagana pa ang skill

Ang isang skill ay walang compiler. Ito ay mga instruction na nakatuon sa isang model, kaya maaari itong huminto sa paggana kahit na ang file ay nananatiling byte-for-byte na pareho. Ang pag-upgrade ng model ay nagbabago sa kung gaano kahigpit sinusunod ang isang mahabang instruction. Ang isang command line tool na tinatawag ng skill ay maaaring mag-rename ng flag. Ang isang URL sa isang reference file ay maaaring magsimulang mag-return ng 404 at ang agent ay magtatrabaho base sa error page.

Walang maingay na failure sa alinman sa mga kasong ito. Sumasagot pa rin ang agent. Ang sagot ay mas malala lang kaysa noong nakaraang buwan, na isang mahirap mapansin na bagay kung isa-isang pull request ang titingnan.

Ano ang nilulutas ng mga tool na ilalabas sa 2026

Maraming solusyon ang lumalabas ngayon, at hindi sila magkasundo kung saan dapat ilagay ang version.

Lockfiles. Ang command line tool na skills mula sa Vercel Labs (vercel-labs/skills, lisensyadong MIT, v1.5.22 noong 5 Agosto 2026) ay nag-i-install ng mga skill mula sa isang git repository patungo sa directory na inaasahan ng iyong agent. Alam nito ang layout para sa mahigit pitumpung agent. Ang npx skills add <repo> ay para sa pag-install, npx skills update para sa pag-upgrade, at npx skills list para ipakita ang mga mayroon ka. Ang record ng mga naka-install ay nakatago bawat user sa halip na bawat repository. May isang open request sa proyektong iyon (issue 283) na humihiling ng command na skills install na mag-re-reinstall ng lahat ng tracked skill mula sa lock file para maging pareho ang set ng mga skill sa pangalawang machine. Basahin ang request na iyon bilang status report. Ang ideya ng lockfile ay settled na. Ang bahagi nito na per-project ay kasalukuyan pang binubuo.

Specs at tests. Ang SkillSpec ay kumukuha ng ibang anggulo. Itinuturing nito ang isang SKILL.md bilang isang contract na dapat i-check sa halip na prose na dapat pagkatiwalaan. Ang layunin nito ay gawing "followable, testable, at provable" ang mga skill. Ang skillspec doctor <path> ay nag-uulat kung saan posibleng maputol ang thread ng isang agent. Ang skillspec boundary map <path> ay nag-uulat kung ano ang kayang maabot ng skill, at ang skillspec boundary assess <path> ay nagra-rank sa mga natuklasan base sa risk. Ito ay isang Rust crate, dual licensed bilang MIT o Apache 2.0, sa version 0.2.2 noong 29 Hulyo 2026. I-install ang pinned version sa halip na ang pinakabago:

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

Ang --locked ay nagbi-build gamit ang mga dependency version kung kailan na-publish ang crate, kaya hindi magbabago ang build mo nang hindi mo alam. Ang skillspec --version ay dapat mag-print ng 0.2.2. Ang ibang numero ay nangangahulugang may mas lumang binary sa iyong PATH na siyang nauuna.

Vendor practice. Inilarawan ng Google kung paano nito bina-build ang mga skill sa google/skills sa isang post tungkol sa kung paano ito mag-build, mag-test, at mag-scale ng agent skills. Alisin ang scale at ang mekanismo ay ordinaryong continuous integration (CI) lamang. Ang bawat skill ay dumadaan sa mga linter para sa frontmatter metadata, bilang ng linya, directory layout, at pagpapangalan bago ito i-merge. Ang isang link checker ay nagpapabagsak sa build kung may URL na nagbabalik ng 404, na nakakahuli sa mga posibleng link na inimbento lang ng agent. Kailangang magbigay ang mga author ng evaluation prompt suite at scoring rubric kasama ng skill. Ang mga naka-schedule na evaluation job ay tumatakbo linggu-linggo laban sa buong library para makahuli ng mga regression, at ang bawat skill ay may nakatalagang owner na inaasahang mag-aayos nito kapag bumaba ang kalidad.

Ang pattern sa ilalim ng tatlong sagot

Hindi mo kailangang pumili ng isa sa mga iyon. Sa ilalim ng mga ito ay may iisang hugis, at ibinibigay ito sa iyo ng plain git.

Isang source of truth. Ang skill ay may iisang home lamang, at bawat repository ay tumutukoy sa home na iyon sa halip na magtabi ng kopya.
Isang pinned version bawat repository. Itinatala ng bawat project ang eksaktong revision na ginagamit nito, kaya ang pag-upgrade ay isang commit sa project na iyon na may author at petsa.
Isang smoke test bawat skill. Isang runnable check na nagpapatunay na ang skill ay naglalabas pa rin ng resultang ipinapangako nito.
Isang review path. Ang pagbabago sa isang shared skill ay dumadaan sa review, at nakikita ng bawat consumer ang diff bago ito tanggapin.

Iyan ang hugis ng isang dependency. Mas mabilis naging shared artifact ang mga skill kaysa sa paglago ng tooling sa paligid nito, kaya ang tooling na pinagkakatiwalaan mo na ang pinakaligtas na gamitin.

Layout para sa maliit na team sa isang self-hosted git remote

Isang repository lang ang naglalaman ng mga skill. Walang ibang nakalagay dito, kaya ang history nito ay nagsisilbing changelog ng mga instruction.

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

Ang mga release ay mga tag. Gumamit ng annotated tags dahil nagdadala ang mga ito ng mensahe at petsa. Isulat ang mensahe bilang dahilan kung bakit kailangan ng consumer ang update:

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

Kung ang remote mo ay Gitea, Forgejo, GitLab, o isang bare repository sa pamamagitan ng SSH sa sarili mong VPS, walang magbabago sa mga susunod na hakbang. Ang lahat ng nakasaad dito ay git at isang symlink lamang.

Pag-pin gamit ang git submodule

Ang isang submodule ay nagtatala ng eksaktong commit ng isa pang repository sa loob ng iyong repository. Ang tala na iyon ang nagsisilbing pin. Sa bawat 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"

Ang symlink ang bahaging nagpapagana nito. Ang isang skill entry sa antas ng project ay maaaring maging symlink patungo sa isang directory sa ibang bahagi ng disk, at sinusundan ito ng Claude Code para basahin ang SKILL.md mula sa target. Kaya naman, naglo-load ang skill bilang isang normal na project skill, habang ang mga byte ay nasa loob ng submodule sa commit na pinili mo.

I-check ang pin:

git submodule status

Ang isang maayos na linya ay nagsisimula sa space, susundan ng commit, pagkatapos ay ang path, at ang pinakamalapit na tag:

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

Ang panimulang - ay nangangahulugang hindi na-initialise ang submodule, kaya ang .claude/skills/api-review ay walang tinutukoy at tahimik na hindi maglo-load ang skill. Ayusin ito gamit ang git submodule update --init. Ang panimulang + ay nangangahulugang ang naka-check out na commit ay iba sa nakatala, kaya ang developer na iyon ay gumagamit ng mga instruction na wala sa iba. Kailangan ng mga bagong clone ang git clone --recurse-submodules, at ang linyang iyon ay dapat nasa README, dahil ang isang simpleng clone ay nag-iiwan sa vendor/agent-skills na walang laman at hindi naglalabas ng error.

Ang pag-upgrade ay sinasadya, na siyang pangunahing layunin nito:

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"

Ang linyang diff ang nagsisilbing review path. Ipinapakita nito ang parehong pagbabago na makikita ng iba pang consuming repo, at angkop ito sa isang pull request.

Pag-pin gamit ang plugin marketplace sa halip

Kung ayaw mong obligahin ang bawat developer na matutunan ang submodules, ang plugin system ng Claude Code ang bahala sa distribution para sa iyo, at gumagana ito laban sa isang self-hosted remote. Maglagay ng catalog sa .claude-plugin/marketplace.json sa loob ng skills repository:

{
  "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"
      }
    }
  ]
}

Dalawang magkaibang source ang kasangkot dito, at ang pagkalito sa dalawa ang karaniwang pagkakamali. Ang marketplace source, kung saan kinukuha ang mismong catalog, ay tumatanggap ng ref para sa branch o tag at hindi tumatanggap ng sha. Ang plugin source sa loob ng catalog ay tumatanggap ng pareho, at kapag parehong naka-set, ang sha ang magiging effective pin. Kaya ang exact-commit pin ay dapat ilagay sa catalog entry.

Ang bawat consuming repository ay magdedeklara ng marketplace sa kanilang committed .claude/settings.json:

{
  "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
  }
}

Ang teammate na nagtitiwala sa project folder ay makakatanggap ng prompt para i-install ang marketplace, at ang plugin ay ma-e-enable para sa kanila nang hindi na kailangan ng wiki page para gawin ito. Ang mga skill ay sasagot sa /team-skills:api-review, dahil ang mga plugin skill ay naka-namespace ayon sa pangalan ng plugin at hindi magkakasalungat sa project skill na may parehong pangalan. Pagkatapos mong mag-push ng bagong tag, mag-re-refresh ang mga consumer gamit ang /plugin marketplace update acme-agents, at pagkatapos ay patakbuhin ang /reload-plugins kung hihilingin ito ng install summary.

Pagsulat ng smoke test para sa isang skill

Ang smoke test ay isang scripted agent run laban sa isang fixture na may alam na fault, kasama ang isang assertion. Tumatakbo ang Claude Code nang non-interactive gamit ang -p, at gumagana roon ang user-invoked skill: ilagay ang /skill-name sa prompt string at ie-expand ito bago magsimula ang 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

Ang fixtures/orders-api.md ay isang maikling file na may isang sadyang fault. Ang assertion ay dapat pangalanan ito ng skill. Nag-e-exit ang jq -e nang non-zero kapag ang filter nito ay nakagawa ng null, kaya ang skill na huminto sa pag-catch ng seeded fault ay magiging sanhi ng pagkabigo ng script. Ang claude mismo ay nag-e-exit nang non-zero kapag nabigo ang run, at ang set -euo pipefail ay ginagawang failed test ang alinman sa mga failure na ito.

Nagbabago ang wording ng sagot ng model sa pagitan ng mga run, kaya huwag mag-assert sa buong pangungusap. Mag-assert sa isang identifier na dapat ilabas ng skill, o sa isang field ng schema na hiniling mo, at panatilihing maliit ang fixture para manatiling mura ang run.

Sa CI, idagdag ang --bare. Kung wala ito, nilo-load ng claude -p ang parehong context na gagamitin ng interactive session, kabilang ang mga hook, plugin, at CLAUDE.md mula sa machine kung saan ito tumatakbo, kaya maaaring mabago ng personal configuration ng isang teammate ang resulta. Nilalaktawan ng bare mode ang lahat ng auto-discovery, na nangangahulugang nilalaktawan din nito ang skill na sinusubukan mo, kaya i-load iyon nang explicit. Hindi rin binabasa ng bare mode ang iyong subscription login, kaya i-set muna ang ANTHROPIC_API_KEY sa environment:

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

Gamit ang --output-format stream-json, ang unang event ng run ay nag-uulat kung aling mga plugin ang na-load at nagdadala ng plugin_errors array para sa mga hindi na-load. I-fail ang CI job kapag hindi empty ang plugin_errors. Nahuhuli nito ang isang pin na nakaturo sa isang revision na wala na, na kung hindi ay lalabas bilang agent na tahimik na binabalewala ang iyong mga house rule.

Ang shared skill ay isang executable instruction

Dalawang feature ang nagpapagawa nito nang literal, at parehong mahalaga ang mga ito kapag galing sa ibang team ang file.

Una, ang isang SKILL.md ay maaaring magpatakbo ng mga shell command bago pa man basahin ng model ang anumang bagay. Ang linyang gaya nito sa body ay nagsisilbing preprocessing:

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

Ang command ay tumatakbo sa machine na naglo-load ng skill, at ang output nito ang pumapalit sa placeholder sa text na natatanggap ng model. Ang isang fenced block na binuksan gamit ang tatlong backtick na sinusundan ng ! ay nagpapatakbo ng ilang command sa parehong paraan. Walang nag-a-approve nito sa run time. Ang pagbabasa ng isang shared skill ay nangangahulugan din ng pagbabasa ng mga command substitution nito.

Pangalawa, ang frontmatter ay maaaring mag-pre-approve ng mga tool. Ang allowed-tools ay nagbibigay ng access sa mga nakalistang tool nang walang permission prompt para sa turn na nag-invoke ng skill. Para sa isang project skill, ang grant na ito ay nagkakabisa kapag tinanggap na ng user ang workspace trust dialog para sa folder. Malinaw na isinasaad ng dokumentasyon ng Claude Code ang konsekwensya: i-review ang mga project skill bago magtiwala sa isang repository, dahil ang isang skill ay maaaring magbigay sa sarili nito ng malawak na tool access.

Kaya ituring ang isang skill bump na parang dependency bump. I-pin ito gamit ang eksaktong commit hangga't maaari, dahil ang isang tag ay maaaring ilipat at ang branch naman ay nagbabago ayon sa depinisyon nito. Sa isang naka-lockdown na machine, ang "disableSkillShellExecution": true sa settings ay pinapalitan ang bawat command substitution ng literal na text na [shell command execution disabled by policy] sa halip na patakbuhin ito, at kung ipapatupad ito sa pamamagitan ng managed settings, hindi ito maaaring i-override ng user. Ang mga bundled at managed skill ay exempted sa setting na ito.

Ang parehong pag-iingat ay dapat ilapat sa kung ano ang binabasa ng isang skill. Ang isang skill na nagpapatakbo ng env o nagbubukas ng config file ay humihila ng anumang mahanap nito patungo sa context ng model, na siyang failure na tinatalakay sa pagpapanatiling ligtas ng mga secret mula sa mga agent na pinapatakbo mo. Ang isang skill na kumukuha ng page o nagpapatakbo ng query ay parehong exposure na nakaturo palabas, dahil ang nakuha (retrieved) na text ay mapupunta sa context na mukhang eksaktong gaya ng mga instruction na isinulat mo—isang boundary na dapat mong basahin bago mo ituro ang isang agent sa sarili mong SearXNG instance para sa web search.

Ano ang dapat basahin sa version bump

Ang diff ng bawat SKILL.md body, dahil ang text na iyon ang susundin ng iyong agent.
Bawat command substitution, dahil tumatakbo ang mga ito sa iyong machine kapag nag-load ang skill.
Anumang pagbabago sa allowed-tools, dahil ang linyang iyon ang nagbibigay ng access sa mga tool nang walang prompt.
Ang test run sa likod ng tag. Kung ang shared repository ay nagpapatakbo ng sarili nitong smoke tests sa CI, dapat ay may green run na naka-attach sa tag na iyong pinipili.

Ang reviewer na hindi kayang basahin ang buong diff sa loob ng sampung minuto ay tumitingin sa isang skill na masyado nang malaki. Hatiin ito. Ang parehong argumento ay nalalapat sa mga repository document na binabasa ng iyong mga agent: panatilihin ang mga permanenteng panuntunan sa mga file na inilarawan sa paghihiwalay ng AGENTS.md at HUMAN.md at ang architectural reasoning sa isang DESIGN.md na isinulat para sa mga agent, at hayaang manatiling mga tiyak na procedure ang mga skill.

Kapag ang pagbabago sa model o tool ay sumira sa isang skill

May mga bagay na nagbabago sa ilalim ng isang skill kahit walang nag-e-edit nito. Ang upgrade sa model ay nagpapabago sa pagiging reliable ng pagsunod sa mahabang instruction, kaya ang isang skill na nakadepende sa pag-abot ng model sa step nine ay maaaring huminto na sa pag-abot nito. Ang isang command line tool ay nagpapalit ng pangalan ng flag, kaya ang agent ay tatakbo gamit ang lumang flag, babasahin ang error, at mag-i-improvise. Ang isang referenced URL ay nagsisimulang mag-return ng 404. Ang isang agent harness ay nagbabago sa paraan ng pagpili nito ng mga skill, kaya ang isang description na dati ay nananalo sa match ay hindi na ngayon. Kapag ang isang procedure ay nagsimulang matapos nang maaga nang ganyan, walang version bump ang makakaayos nito at ang mga instruction mismo ay nangangailangan ng structure na pumipilit sa mga huling step, na siyang approach sa likod ng the unlazy skill and its Depth Tree method.

Ito ang dahilan kung bakit ang smoke test ang may pinakamabigat na papel sa setup na ito. Patakbuhin ang test ng bawat skill ayon sa schedule at tuwing may push. Ang Google ay nagpapatakbo ng kanilang evaluation jobs linggu-linggo laban sa buong library dahil dito, at ang isang lingguhang cron job sa isang maliit na VPS ay sapat na para sa isang team na may sampung skill. Ito lang ang tanging paraan para malaman mo ang sira bago pa ito mapansin ng developer.

Nakakatulong din ang portability. Ang Agent Skills spec ay naglilimita sa frontmatter sa anim na key, kaya ang isang skill na isinulat ayon sa spec na iyon ay gagana sa mga tool na labas sa ginamit mo noong isinulat mo ito, habang ang bawat harness-specific key na idadagdag mo ay isang taya sa isang vendor. Ang pagsusulat ng mga skill na nakaka-survive sa model swap ay isang disiplina sa sarili nito, na tinatalakay sa making a skill work on any model.

FAQ

Paano ko ibabahagi ang isang agent skill sa maraming repository?

Ilagay ang skill sa isang dedikadong git repository, lagyan ng tag ang mga release nito, at hayaang mag-reference ang bawat consuming project ng isang tag sa halip na kopyahin ang file. Dalawang mekanismo ang gumagana rito. Ang git submodule ay nagtatala ng eksaktong commit, at ang symlink mula sa .claude/skills/<name> patungo sa submodule ay nagpapagana rito bilang isang normal na project skill. Ginagawa rin ito ng isang plugin marketplace sa pamamagitan ng /plugin, kung saan ang pin ay idinedeklara sa .claude/settings.json ng consuming repository. Parehong inilalagay ng mga ito ang bersyon sa git history, kaya matutukoy mo kung anong mga instruction ang nagresulta sa isang partikular na agent run.

Maaari ko bang i-pin ang isang agent skill sa isang partikular na bersyon?

Hindi mula sa loob ng SKILL.md, dahil walang version key ang frontmatter na iyon. Ang pin ay dapat magmula sa layer sa labas ng file. Ang git submodule ay awtomatikong nag-pi-pin ng eksaktong commit. Sa isang Claude Code plugin marketplace, ang plugin source ay tumatanggap ng ref para sa isang branch o tag at sha para sa eksaktong commit, at ang sha ang mananaig kapag parehong naroroon. Ang marketplace source mismo ay tumatanggap lamang ng ref. Mas mainam na gamitin ang commit pin, dahil ang isang tag ay maaaring ilipat matapos mo itong ma-review.

Ano ang dapat i-assert ng isang skill smoke test?

Mag-assert sa isang bagay na stable. Patakbuhin ang skill nang non-interactive laban sa isang fixture na may kilalang fault, pagkatapos ay tingnan kung ang isang partikular na identifier ay lumalabas sa output, halimbawa ay isang rule id na dapat i-report ng skill. Ang pag-request ng structured output gamit ang --output-format json at --json-schema ay ginagawang eksakto ang check, at ang jq -e ay nagpapabigo sa script kapag wala ang value. Huwag kailanman mag-assert sa isang buong pangungusap, dahil binabago ng model ang mga sagot nito sa bawat run.

Ligtas bang mag-install ng shared skill mula sa repository ng ibang team?

Ituring ito bilang isang code dependency, dahil ito ay executable instruction. Ang isang SKILL.md ay maaaring magpatakbo ng mga shell command sa load time sa pamamagitan ng ! command substitution form, at ang allowed-tools field sa frontmatter ay maaaring mag-pre-approve ng mga tool nang walang prompt. Basahin ang diff sa bawat bump, mag-pin sa eksaktong commit sa halip na sa branch, at mas piliin ang source na kontrolado ng sarili mong team. Sa mga managed machine, ang "disableSkillShellExecution": true sa settings ay humaharang sa pagtakbo ng mga command substitution.

Gagana ba ang isang shared skill sa ibang mga agent maliban sa Claude Code?

Depende ito sa kung anong frontmatter ang ginagamit mo. Ang Agent Skills spec ay nagtatakda ng anim na key: name, description, license, compatibility, metadata at allowed-tools. Ang isang skill na limitado sa mga ito ay gagana sa mga tool na nagpapatupad ng spec, at gagana rin ito sa Claude Code nang walang pagbabago. Ang mga harness-specific key at body feature na labas sa spec ay binabalewala o nare-reject sa ibang lugar, kaya iwasang isama ang mga ito sa anumang skill na balak mong ibahagi nang malawakan.

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

Paano magbahagi ng agent skills sa iba't ibang repo

Kung saan nakatira ang isang skill, at bakit mahirap ang pag-share nito

Problema isa: walong kopya na tahimik na naghihiwalay

Problema dalawa: walang naka-pin na bersyon

Problema tatlo: walang nakakaalam kung gumagana pa ang skill

Ano ang nilulutas ng mga tool na ilalabas sa 2026

Ang pattern sa ilalim ng tatlong sagot

Layout para sa maliit na team sa isang self-hosted git remote

Pag-pin gamit ang git submodule

Pag-pin gamit ang plugin marketplace sa halip

Pagsulat ng smoke test para sa isang skill

Ang shared skill ay isang executable instruction

Ano ang dapat basahin sa version bump

Kapag ang pagbabago sa model o tool ay sumira sa isang skill

FAQ

Paano ko ibabahagi ang isang agent skill sa maraming repository?

Maaari ko bang i-pin ang isang agent skill sa isang partikular na bersyon?

Ano ang dapat i-assert ng isang skill smoke test?

Ligtas bang mag-install ng shared skill mula sa repository ng ibang team?

Gagana ba ang isang shared skill sa ibang mga agent maliban sa Claude Code?