SSD Nodes Learn Hosting plans →
கல்வி வழிகாட்டிகள் Matt Connorஆல் Matt Connor · புதுப்பிக்கப்பட்டது 2026-08-30

repos இடையே agent skills பகிரும் சரியான முறை

எட்டு repos-ல் skill-ஐ நகலெடுத்தால் copies drift ஆகும். ஒரே shared repo-வை source of truth ஆக வைத்து, ஒவ்வொரு project-லும் version-ஐ pin செய்து review செய்யுங்கள்.

repos இடையே agent skills-ஐ எவ்வாறு பகிர்வது

repos-இடையே agent skills-ஐ பகிர, file-ஐ நகலெடுப்பதை நிறுத்தி, அதனை dependency-ஆகப் பயன்படுத்தத் தொடங்குங்கள். ஒரு skills repository-ஐ மட்டும் பராமரித்து, அதற்கு tag உருவாக்கி, ஒவ்வொரு project-மும் ஒரு tag-ஐ pin செய்யுமாறு அமைக்கவும். பின்னர், ஒவ்வொரு skill-க்கும் smoke test சேர்க்கவும். Dependency bump-ஐ review செய்வது போல, ஒவ்வொரு bump-ஐயும் review செய்யவும்.

இதில் நான்கு பகுதிகள் உள்ளன: பகிரப்பட்ட 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-களும் அதில் இருக்கலாம். இந்த unit உங்களுக்கு புதியதாக இருந்தால், முதலில் agent skill என்றால் என்ன, SKILL.md எவ்வாறு செயல்படுகிறது என்பதைப் படிக்கவும். இந்தப் பக்கம் அந்த unit-ஐச் சுற்றியுள்ள supply chain குறித்து விளக்குகிறது.

ஒரு skill எங்கு உள்ளது, பகிர்வது ஏன் கடினம்

Claude Code மூன்று இடங்களில் இருந்து skills-ஐ ஏற்றுகிறது. ஒவ்வொரு பாதையையும் skills documentation குறிப்பிடுகிறது.

  • ~/.claude/skills/<skill-name>/SKILL.md தனிப்பட்ட பயன்பாட்டுக்கானது. இது உங்கள் அனைத்து projects-லும் ஏற்றப்படும்; வேறு யாருடைய projects-லும் ஏற்றப்படாது.
  • .claude/skills/<skill-name>/SKILL.md project நிலைக்கானது. அந்த repository-ஐ checkout செய்யும் அனைவருக்கும் இது ஏற்றப்படும்.
  • <plugin>/skills/<skill-name>/SKILL.md ஒரு plugin-க்குள் package செய்யப்பட்டிருக்கும். அந்த plugin enabled நிலையில் உள்ள இடங்களிலெல்லாம் இது ஏற்றப்படும்.

ஒரு குழுவுக்கு இரண்டாவது இடம்தான் பயனுள்ளது. அது 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-வில் உள்ள தவறான instruction-ஐ சரிசெய்கிறார்; மற்ற ஏழு பிரதிகளை அவர் மாற்றுவதில்லை. வேறொருவர் orders-ல் pagination குறித்த rule-ஐச் சேர்க்கிறார். இப்போது agent எந்த directory-யிலிருந்து தொடங்கியது என்பதைப் பொறுத்து, ஒரே skill name-க்கு இரண்டு வேறுபட்ட reviews கிடைக்கின்றன. இதை எந்த developer-க்கும் தெரியாது.

இங்கு error state இல்லாததால் இந்த தோல்வி அமைதியாக நிகழ்கிறது. Skill என்பது prose மட்டுமே. காலாவதியான instruction நம்பிக்கையுடன் தவறான பதிலை உருவாக்கும்; இதுவே அதிகச் செலவுடைய தோல்வி வகையாகும். உங்கள் copy-ஐ வேறு ஒருவரின் copy-யுடன் agent ஒப்பிடுவதில்லை. ஆகவே, இரண்டு repo-களில் முரண்பாடு இருப்பதை ஒருவர் கவனிப்பதே ஒரே signal ஆகும்.

Problem two: version-ஐ எதுவும் pin செய்யப்படவில்லை

ஒரு team skills-ஐ ஒரே இடத்தில் வைத்திருந்தாலும், வழக்கமான sharing முறை copy step ஆகும்: ஒரு setup script, onboarding doc-ல் உள்ள curl line, அல்லது ஒரு folder-ஐ sync செய்யும் shell alias. இவை அனைத்தும் branch-ன் தற்போதைய head-ல் இருப்பதையே install செய்யும்.

இதனால், ஒரே application-ன் ஒரே commit-ல் இருக்கும் இரண்டு developers வெவ்வேறு instructions-ஐ இயக்கக்கூடும். காரணம், அவர்கள் வெவ்வேறு நாட்களில் sync செய்திருக்கலாம். மேலும், agent run தோல்வியடைந்த பிறகு முக்கியமான கேள்விக்கும் நீங்கள் பதிலளிக்க முடியாது: இதை எந்த version-ன் skill உருவாக்கியது? பதிவு செய்யப்பட்ட revision இல்லையெனில், அந்த run-ஐ மீண்டும் உருவாக்க முடியாது. எனவே bug report-ல் பயனுள்ள நடவடிக்கை எடுக்க முடியாது.

சிக்கல் மூன்று: அந்த skill இன்னும் செயல்படுகிறதா என்பது யாருக்கும் தெரியாது

ஒரு skill-க்கு compiler இல்லை. அது ஒரு model-க்கு வழங்கப்படும் instructions ஆகும். எனவே, file byte-by-byte அப்படியே இருந்தாலும் அது செயல்படாமல் போகலாம். Model upgrade செய்யப்பட்டால், நீண்ட instruction எவ்வளவு நெருக்கமாகப் பின்பற்றப்படுகிறது என்பது மாறும். அந்த skill பயன்படுத்தும் command line tool-ல் ஒரு flag-ன் பெயர் மாற்றப்படலாம். Reference file-ல் உள்ள URL 404 status திருப்பத் தொடங்கலாம்; அப்போது agent அந்த error page-ஐ அடிப்படையாகக் கொண்டு செயல்படும்.

இந்த நிலைகளில் எதுவும் வெளிப்படையாகத் தோல்வியடையாது. Agent தொடர்ந்து பதிலளிக்கும். ஆனால் அந்தப் பதில் கடந்த மாதத்தைவிட மோசமாக இருக்கும். ஒவ்வொரு pull request-ஐ தனித்தனியாகப் பார்க்கும்போது இதைக் கண்டறிவது கடினம்.

2026-ல் கிடைக்கும் tools தீர்க்கும் பிரச்சினைகள்

பல தீர்வுகள் தற்போது வெளிவருகின்றன. ஆனால் version எங்கு இருக்க வேண்டும் என்பதில் அவை வெவ்வேறு கருத்துகளைக் கொண்டுள்ளன.

Lockfiles. Vercel Labs-ன் skills command line tool (vercel-labs/skills, MIT licensed, 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 செய்யப்பட்டவற்றின் record ஒவ்வொரு 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 எந்த இடத்தில் தொடரை இழக்கக்கூடும் என்பதைக் காட்டுகிறது. skillspec boundary map <path> அந்த skill எவற்றை அணுக முடியும் என்பதைக் காட்டுகிறது. skillspec boundary assess <path> அந்தக் கண்டறிதல்களை risk அடிப்படையில் வரிசைப்படுத்துகிறது. இது Rust crate ஆகும். இது MIT அல்லது Apache 2.0 என்ற dual license-ன் கீழ் வழங்கப்படுகிறது. 29 July 2026 நிலவரப்படி இதன் version 0.2.2. சமீபத்திய version-ஐ விட pinned 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-ல் விவரித்துள்ளது. அதன் பெரிய அளவைத் தவிர்த்து பார்த்தால், பயன்படுத்தப்படும் mechanism வழக்கமான continuous integration (CI) ஆகும். ஒவ்வொரு skill-உம் merge செய்யப்படுவதற்கு முன் frontmatter metadata, line count, directory layout மற்றும் naming ஆகியவற்றுக்கான linters-ல் pass ஆக வேண்டும். 404-ஐ return செய்யும் எந்த URL-யிலும் link checker build-ஐ fail செய்யும். இதனால் agent உருவாக்கியதாகத் தோன்றக்கூடிய ஆனால் உண்மையில் இல்லாத link கண்டறியப்படுகிறது. ஒவ்வொரு skill-உடனும் authors evaluation prompt suite மற்றும் scoring rubric-ஐ வழங்க வேண்டும். பின்னர் scheduled evaluation jobs முழு library-க்கும் வாரந்தோறும் இயங்கி regressions-ஐ கண்டறியும். மேலும், ஒவ்வொரு skill-க்கும் ஒரு named owner இருப்பார். Quality குறைந்தால் அதைச் சரிசெய்வது அவருடைய பொறுப்பாகும்.

மூன்று பதில்களுக்கும் அடிப்படையான அமைப்பு

அந்த மூன்றில் ஒன்றைத் தேர்ந்தெடுக்க வேண்டியதில்லை. அவற்றின் அடியில் ஒரே அமைப்பு உள்ளது; plain git அதன் அனைத்து பகுதிகளையும் வழங்குகிறது.

  1. ஒரே truth source. ஒவ்வொரு skill-க்கும் சரியாக ஒரு இருப்பிடம் இருக்கும். ஒவ்வொரு repository-யும் copy வைத்திருப்பதற்குப் பதிலாக அந்த இருப்பிடத்தையே குறிக்கும்.
  2. ஒவ்வொரு repository-க்கும் pinned version. ஒவ்வொரு project-மும் பயன்படுத்தும் exact revision-ஐ பதிவு செய்கிறது. ஆகவே upgrade என்பது அந்த project-ல் author மற்றும் date கொண்ட ஒரு commit ஆகும்.
  3. ஒவ்வொரு skill-க்கும் smoke test. Skill உறுதியளிக்கும் result-ஐ இன்னும் உருவாக்குகிறது என்பதை நிரூபிக்கும் ஒரு runnable check இருக்கும்.
  4. Review path. Shared skill-ல் செய்யப்படும் மாற்றம் review வழியாகச் செல்லும். ஒவ்வொரு consumer-மும் அதை ஏற்கும் முன் diff-ஐ பார்க்கும்.

இதுவே dependency-யின் அமைப்பு. Tooling அதற்கேற்ப வளர்வதற்கும் முன்பே skills shared artifact-ஆக மாறிவிட்டன. எனவே நீங்கள் ஏற்கனவே நம்பும் tooling-ஐப் பயன்படுத்துவதே பாதுகாப்பான அணுகுமுறையாகும்.

சுயமாக host செய்யப்படும் git remote-ல் ஒரு சிறிய குழுவுக்கான layout

Skills அனைத்தும் ஒரே repository-ல் இருக்கும். வேறு எதுவும் அதில் இருக்காது. எனவே, அதன் history instructions-ன் 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-ஐ pin செய்தல்

ஒரு submodule, மற்றொரு repository-யின் ஒரு குறிப்பிட்ட commit-ஐ உங்கள் repository-க்குள் பதிவு செய்கிறது. அந்தப் பதிவே 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 level-ல் உள்ள ஒரு skill entry, disk-ல் வேறு இடத்தில் உள்ள directory-க்கான symlink ஆக இருக்கலாம். Claude Code அந்த symlink-ஐப் பின்தொடர்ந்து target-இலிருந்து SKILL.md-ஐ வாசிக்கும். ஆகவே skill, வழக்கமான project skill போல load ஆகும்; அதன் files, நீங்கள் தேர்ந்தெடுத்த 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-க்கான வழியாகும். மற்ற அனைத்து consuming repos-லும் காணப்படும் அதே மாற்றத்தை இது காட்டுகிறது. மேலும், இது pull request-க்குள் எளிதாகப் பரிசீலிக்க முடியும்.

Plugin marketplace மூலம் pin செய்வதற்கான மாற்று

ஒவ்வொரு 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 இரண்டையும் ஏற்கும். இரண்டும் அமைக்கப்பட்டால், sha தான் effective 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 செய்ய prompt காட்டப்படும். இதனால் wiki page மூலம் installation செய்யச் சொல்லத் தேவையின்றி, plugin அவர்களுக்காக enabled செய்யப்படும். அதன் பிறகு skills, /team-skills:api-review என்ற பெயரிடலுக்குப் பதிலளிக்கும். காரணம், plugin skills-க்கு plugin name அடிப்படையிலான namespace இருக்கும்; அதே பெயரைக் கொண்ட project skill-உடன் அவை மோதாது. புதிய tag-ஐ push செய்த பிறகு, consumers /plugin marketplace update acme-agents மூலம் refresh செய்ய வேண்டும். Install summary அவ்வாறு கேட்குமானால், பின்னர் /reload-plugins-ஐ இயக்கவும்.

ஒரு skill-க்கான smoke test எழுதுதல்

Smoke test என்பது அறியப்பட்ட fault கொண்ட fixture-க்கு எதிராக இயக்கப்படும் scripted agent run மற்றும் ஒரு assertion ஆகியவற்றைக் கொண்டது. Claude Code, -p உடன் non-interactive முறையில் இயங்கும். User-invoked skill அங்கும் செயல்படும்: prompt string-ல் /skill-name-ஐ சேர்த்தால், run தொடங்குவதற்கு முன் அது விரிவாக்கப்படும்.

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

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

fixtures/orders-api.md என்பது ஒரு திட்டமிட்ட fault கொண்ட சிறிய file ஆகும். அந்த fault-ஐ skill பெயரிட்டு குறிப்பிட வேண்டும் என்பதே assertion. அதன் filter null-ஐ உருவாக்கும்போது jq -e non-zero-ஆக நிறைவடையும். எனவே, seed செய்யப்பட்ட fault-ஐ இனி கண்டறியாத skill இந்த script-ஐ தோல்வியடையச் செய்யும். Run தோல்வியடைந்தால் claude தானாகவே non-zero-ஆக நிறைவடையும். set -euo pipefail இந்த இரண்டு தோல்விகளில் ஏதேனும் ஒன்றை failed test-ஆக மாற்றும்.

Runs-க்கு இடையில் model தனது பதில்களை வேறு விதமாக மறுஉருவாக்கும். எனவே, முழு sentence-ஐ அடிப்படையாகக் கொண்டு ஒருபோதும் assertion அமைக்க வேண்டாம். Skill வெளியிட வேண்டிய identifier-ஐ அல்லது நீங்கள் கோரிய schema-வின் ஒரு field-ஐ அடிப்படையாகக் கொண்டு assertion அமைக்கவும். Run குறைந்த செலவில் நிறைவடைய fixture-ஐ சிறியதாக வைத்திருக்கவும்.

CI-ல் --bare-ஐ சேர்க்கவும். இது இல்லையெனில், interactive session பயன்படுத்தும் அதே context-ஐ claude -p 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 எந்த plugins load செய்யப்பட்டன என்பதைத் தெரிவிக்கும். Load ஆகாத plugins-க்கான plugin_errors array-யையும் அது கொண்டிருக்கும். plugin_errors non-empty ஆக இருந்தால் CI job-ஐ தோல்வியடையச் செய்யவும். இனி இல்லாத revision-ஐ குறிக்கும் pin-ஐ இது கண்டறியும். இல்லையெனில், agent உங்கள் house rules-ஐ அமைதியாகப் புறக்கணிப்பது போலத் தோன்றும்.

ஒரு skill என்பது செயல்படுத்தக்கூடிய instruction

இந்த literal பொருளை இரண்டு அம்சங்கள் உறுதிப்படுத்துகின்றன. அந்த file மற்றொரு team-இலிருந்து வரும்போது, இரண்டும் முக்கியமானவை.

முதலில், model எதையும் படிப்பதற்கு முன் ஒரு SKILL.md shell commands-ஐ இயக்க முடியும். Body-யில் உள்ள இதுபோன்ற ஒரு line preprocessing ஆகும்:

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

skill-ஐ load செய்யும் machine-ல் command இயக்கப்படும். அதன் output, model பெறும் text-ல் placeholder-ஐ மாற்றும். மூன்று backticks-க்கு அடுத்து ! கொண்டு தொடங்கும் fenced block-ம் இதே முறையில் பல commands-ஐ இயக்கும். இவற்றில் எதற்கும் run time-ல் யாரும் approval வழங்குவதில்லை. Shared skill-ஐ படிப்பது என்பது அதன் command substitutions-ஐ படிப்பதுமாகும்.

இரண்டாவதாக, frontmatter tools-ஐ முன்கூட்டியே approve செய்ய முடியும். allowed-tools பட்டியலிடப்பட்ட tools-ஐ, skill-ஐ invoke செய்த turn-க்கான permission prompt இல்லாமல் grant செய்கிறது. Project skill-க்கு, அந்த folder-க்கான workspace trust dialog-ஐ ஒருவர் ஏற்றுக்கொண்டதும் இந்த grant நடைமுறைக்கு வரும். Claude Code documentation இதன் விளைவைக் தெளிவாகக் கூறுகிறது: repository-ஐ trust செய்வதற்கு முன் project skills-ஐ review செய்ய வேண்டும்; ஏனெனில் ஒரு skill தனக்கே பரந்த tool access-ஐ grant செய்ய முடியும்.

எனவே, ஒரு skill bump-ஐ dependency bump போலவே கையாளவும். Mechanism அனுமதிக்கும் இடங்களில் exact commit மூலம் pin செய்யவும். ஏனெனில் tag மாற்றப்படலாம்; branch என்பது வரையறையிலேயே நகரக்கூடியது. Lock செய்யப்பட்ட machine-ல், settings-இல் உள்ள "disableSkillShellExecution": true ஒவ்வொரு command substitution-ஐயும் இயக்காமல், அதற்குப் பதிலாக literal text [shell command execution disabled by policy] ஆக மாற்றும். Managed settings மூலம் இதை apply செய்தால், user அதை override செய்ய முடியாது. Bundled மற்றும் managed skills இந்த setting-இலிருந்து விலக்கு பெறுகின்றன.

ஒரு skill எதைப் படிக்கிறது என்பதற்கும் இதே கவனம் தேவை. env-ஐ இயக்கும் அல்லது config file-ஐ திறக்கும் skill, அதில் கிடைப்பதை model-ன் context-க்குள் கொண்டு வரும். இது நீங்கள் இயக்கும் agents-இலிருந்து secrets-ஐ விலக்கி வைத்தல் பகுதியில் விவரிக்கப்பட்ட failure ஆகும். Page-ஐ fetch செய்யும் அல்லது query-ஐ இயக்கும் skill, இதே exposure-ஐ வெளிப்புறமாக ஏற்படுத்துகிறது. Retrieved text, நீங்கள் எழுதிய instructions போலவே context-க்குள் சேர்கிறது. எனவே web search-க்காக உங்கள் சொந்த SearXNG instance-ஐ agent-க்கு வழங்குதல் செய்வதற்கு முன், இந்த boundary பற்றி படிப்பது அவசியம்.

version bump செய்யும்போது படிக்க வேண்டியவை

  • ஒவ்வொரு SKILL.md body-யின் diff-ஐப் படிக்க வேண்டும்; ஏனெனில் அந்த உரையே உங்கள் agent பின்பற்றும் instruction ஆகும்.
  • ஒவ்வொரு command substitution-ஐயும் படிக்க வேண்டும்; skill load ஆகும்போது அவை உங்கள் machine-ல் இயங்கும்.
  • allowed-tools-ல் செய்யப்பட்ட எந்த மாற்றத்தையும் படிக்க வேண்டும்; அந்த வரி prompt இல்லாமல் tools-ஐ வழங்குகிறது.
  • tag-க்கு பின்னால் இயங்கிய test run-ஐப் படிக்க வேண்டும். Shared repository தனது smoke tests-ஐ CI-ல் இயக்கினால், நீங்கள் pin செய்யும் tag-க்கு இணைக்கப்பட்ட green run இருக்க வேண்டும்.

ஒரு reviewer பத்து நிமிடங்களில் முழு diff-ஐப் படிக்க முடியவில்லை என்றால், அந்த skill அளவுக்கு அதிகமாக வளர்ந்துள்ளது. அதை பிரிக்க வேண்டும். உங்கள் agents படிக்கும் repository documents-க்கும் இதே விதி பொருந்தும்: நிலையான rules-ஐ AGENTS.md மற்றும் HUMAN.md பிரிப்பு-ல் குறிப்பிடப்பட்ட files-ல் வைத்திருக்க வேண்டும்; architectural reasoning-ஐ agents-க்காக எழுதப்பட்ட DESIGN.md-ல் வைக்க வேண்டும்; skills-ஐ குறுகிய procedures-ஆக வைத்திருக்க வேண்டும்.

ஒரு model அல்லது tool மாற்றம் skill-ஐ பாதிக்கும்போது

யாரும் skill-ஐத் திருத்தாமல், அதன் அடிப்படையில் பல விஷயங்கள் மாறலாம். ஒரு model upgrade, நீண்ட instruction-ஐப் பின்பற்றும் நம்பகத்தன்மையை மாற்றலாம். இதனால், ஒன்பதாவது step-ஐ model அடையும் என்று சார்ந்திருந்த skill, அங்கு செல்வதை நிறுத்தலாம். ஒரு command line tool, flag-ன் பெயரை மாற்றலாம். அப்போது agent பழைய flag-ஐ இயக்கி, error-ஐப் படித்து, தன்னிச்சையாக அடுத்த நடவடிக்கையைத் தேர்ந்தெடுக்கலாம். குறிப்பிடப்பட்ட URL, 404-ஐத் திருப்பி அனுப்பத் தொடங்கலாம். ஒரு agent harness, skills-ஐத் தேர்ந்தெடுக்கும் முறையை மாற்றலாம். இதனால் முன்பு match-ல் வென்ற description இனி வெல்லாமல் போகலாம். ஒரு procedure இவ்வாறு முன்கூட்டியே முடிவடையத் தொடங்கினால், எந்த version bump-உம் அதைச் சரிசெய்யாது. அதற்குப் பதிலாக, instructions-க்கு கடைசி steps கட்டாயமாக இயங்கும் வகையிலான structure தேவை. unlazy skill மற்றும் அதன் Depth Tree method இதையே அணுகுமுறையாகக் கொண்டுள்ளது.

இதனால்தான் இந்த arrangement-ல் smoke test முக்கியப் பங்கைக் கொண்டுள்ளது. ஒவ்வொரு skill-ன் test-ஐ push நேரத்தில் மட்டுமல்லாமல், திட்டமிட்ட schedule-லும் இயக்கவும். இந்தக் காரணத்திற்காக Google தனது முழு library-க்கு எதிராக evaluation jobs-ஐ வாரந்தோறும் இயக்குகிறது. பத்து skills கொண்ட ஒரு team-க்கு சிறிய VPS-ல் இயங்கும் weekly cron job போதுமானது. Developer பிரச்சினையை அறியும் முன்பே breakage பற்றி அறிய இதுவே ஒரே வழி.

Portability-யும் உதவுகிறது. Agent Skills spec, frontmatter-ஐ ஆறு keys-க்கு வரையறுக்கிறது. ஆகவே, அந்த spec-க்கு ஏற்ப எழுதப்பட்ட skill, அதற்காக எழுதப்பட்ட tool-ஐத் தாண்டிய பிற tools-லும்கூட load ஆகும். அதே நேரத்தில், நீங்கள் சேர்க்கும் ஒவ்வொரு harness-specific key-உம் ஒரு vendor மீது வைக்கும் நம்பிக்கையாகும். Model மாற்றத்திற்குப் பிறகும் இயங்கும் skills-ஐ எழுதுவது தனித்துவமான ஒரு discipline. இது எந்த model-லிலும் skill இயங்கச் செய்வது என்ற பகுதியில் விளக்கப்பட்டுள்ளது.

FAQ

பல repositories-ல் ஒரே agent skill-ஐ எவ்வாறு பகிர்வது?

skill-ஐ தன dedicated git repository-ல் வைக்கவும், அதில் releases-க்கு tags உருவாக்கவும். ஒவ்வொரு பயன்படுத்தும் project-மும் file-ஐ copy செய்வதற்குப் பதிலாக ஒரு tag-ஐ reference செய்ய வேண்டும். இதற்கு இரண்டு முறைகள் உள்ளன. git submodule ஒரு exact 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 இல்லை. File-ஐச் சுற்றியுள்ள layer-ல்தான் pin குறிப்பிடப்பட வேண்டும். git submodule இயல்பாகவே exact commit-ஐ pin செய்கிறது. Claude Code plugin marketplace-ல், plugin source branch அல்லது tag-க்கு ref-ஐ ஏற்கிறது. Exact commit-க்கு sha பயன்படுத்தப்படுகிறது. இரண்டும் இருந்தால் sha-க்கே முன்னுரிமை கிடைக்கும். Marketplace source தானாகவே ref-ஐ மட்டுமே ஏற்கிறது. Commit pin-ஐப் பயன்படுத்துவது சிறந்தது. நீங்கள் மதிப்பாய்வு செய்த பிறகு ஒரு tag-ஐ மாற்றிவிட முடியும்.

skill smoke test எதை உறுதிப்படுத்த வேண்டும்?

நிலையான முடிவை உறுதிப்படுத்தவும். அறியப்பட்ட fault உள்ள fixture-க்கு எதிராக skill-ஐ non-interactively இயக்கவும். பின்னர் output-ல் குறிப்பிட்ட identifier தோன்றுகிறதா என்பதைச் சரிபார்க்கவும். உதாரணமாக, skill report செய்ய வேண்டிய rule id-ஐப் பார்க்கலாம். --output-format json மற்றும் --json-schema மூலம் structured output கோரினால் check துல்லியமாகும். Value இல்லாதபோது jq -e script-ஐ fail செய்யும். முழு sentence-ஐ ஒருபோதும் assert செய்ய வேண்டாம். ஒவ்வொரு run-லும் model தனது பதிலை வேறு விதமாக எழுதலாம்.

மற்றொரு team-ன் repository-லிருந்து shared skill-ஐ install செய்வது பாதுகாப்பானதா?

அதை code dependency ஆகக் கருதவும். காரணம், அது executable instruction ஆகும். ஒரு SKILL.md, ! command substitution form மூலம் load நேரத்தில் 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, பிற இடங்களில் புறக்கணிக்கப்படலாம் அல்லது நிராகரிக்கப்படலாம். ஆகவே, பரவலாகப் பகிர intended செய்யும் எந்த skill-லும் அவற்றைச் சேர்க்க வேண்டாம்.

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