Agent skills-ஐ பல repositories-ல் பகிர்வது எப்படி?

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

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

இது நான்கு பகுதிகளைக் கொண்டது: பகிரப்பட்ட ஒரு source of truth, ஒவ்வொரு repository-க்கும் ஒரு pinned version, ஒவ்வொரு skill-க்கும் ஒரு smoke test, மற்றும் ஒரு ஆய்வு வழிமுறை (review path). ஒவ்வொரு பகுதியும் ஏன் தேவைப்படுகிறது, 2026-ல் வெளியாகும் கருவிகள் இதை எவ்வாறு கையாளுகின்றன, மற்றும் எந்தவொரு வெளிச் சேவைகளும் இன்றி self-hosted git remote-ல் இதை முழுமையாக எவ்வாறு கட்டமைப்பது என்பதை கீழே உள்ளவை விளக்குகின்றன.

Agent skill என்பது ஒரு SKILL.md கோப்பு, மற்றும் அதற்குத் தேவையான scripts மற்றும் reference கோப்புகளைக் கொண்ட ஒரு folder ஆகும். அந்த அலகு புதியது என்றால், முதலில் agent skill என்றால் என்ன மற்றும் SKILL.md எவ்வாறு செயல்படுகிறது என்பதைப் படிக்கவும். இந்தப் பக்கம் அந்த அலகு தொடர்பான supply chain-ஐப் பற்றியது.

திறன்கள் எங்கே சேமிக்கப்படுகின்றன மற்றும் பகிர்வதில் உள்ள சிக்கல்கள்

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

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

குழுவிற்குப் பயனுள்ளது இரண்டாவது வகைதான், ஏனெனில் இது commit செய்யப்படுகிறது மற்றும் repository-ஐ clone செய்யும் அனைவருக்கும் இது கிடைக்கிறது. ஆனால், சிக்கல் அங்கிருந்துதான் தொடங்குகிறது. .claude/skills/-ல் உள்ள ஒரு திறன் ஒரு குறிப்பிட்ட repository-க்கு மட்டுமே சொந்தமானது. உங்களிடம் எட்டு repository-கள் இருந்தால், அந்தத் திறன் எட்டு முறை நகலெடுக்கப்படும்.

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 இல்லை. எந்த நகல் புதியது என்பதைப் பதிவு செய்ய கோப்பிற்குள் எந்த வசதியும் இல்லை. இது நியாயமானதுதான், ஏனெனில் ஒரு திறன் என்பது ஒரு package-ஐ விட ஒரு ஆவணம் (document) போன்றது. இதன் பொருள், versioning என்பது கோப்பைச் சுற்றியுள்ள அடுக்கிலிருந்துதான் வர வேண்டும், அந்த அடுக்கைப் பராமரிப்பது உங்கள் பொறுப்பு.

சிக்கல் ஒன்று: அமைதியாக வேறுபடும் எட்டு நகல்கள்

முதல் நாளில் copy-paste சரியாக வேலை செய்யும். அறுபதாவது நாளில் அது தோல்வியடையும். யாரோ ஒருவர் payments repo-வில் உள்ள தவறான instruction-ஐ சரிசெய்துவிட்டு, மற்ற ஏழு நகல்களை மாற்ற மறந்துவிடுவார். வேறொருவர் orders-ல் pagination குறித்த விதியைச் சேர்ப்பார். இப்போது, agent எந்த directory-ல் தொடங்கப்பட்டது என்பதைப் பொறுத்து, ஒரே skill பெயர் இரண்டு வெவ்வேறு முடிவுகளைத் தரும். இது குறித்து எந்த developer-க்கும் தெரியாது.

எந்த error நிலையும் இல்லாததால், இந்தத் தோல்வி அமைதியாக நடக்கும். ஒரு skill என்பது உரை வடிவிலானது (prose). காலாவதியான instruction, நம்பிக்கையான ஆனால் தவறான பதிலை உருவாக்கும்; இதுவே அதிக செலவை ஏற்படுத்தும். உங்கள் நகலை மற்றவர்களுடன் ஒப்பிட்டுப் பார்க்க agent-ல் எந்த வசதியும் இல்லை. எனவே, இரண்டு repo-க்களும் முரண்படுவதை யாராவது ஒருவர் கவனிப்பது மட்டுமே இதற்கான ஒரே அறிகுறியாகும்.

சிக்கல் இரண்டு: பதிப்பு (version) எதிலும் நிலைநிறுத்தப்படவில்லை

ஒரு குழு தனது திறன்களை (skills) ஒரே இடத்தில் வைத்திருந்தாலும், பொதுவாகப் பகிரும் முறை ஒரு நகல் எடுக்கும் படியாகவே உள்ளது: ஒரு setup script, onboarding ஆவணத்தில் உள்ள ஒரு curl வரி, அல்லது ஒரு கோப்புறையை ஒத்திசைக்கும் (sync) shell alias. இவை அனைத்தும் அந்தந்த நேரத்தில் branch-ன் தொடக்கத்தில் (head) என்ன இருக்கிறதோ, அதைத்தான் நிறுவுகின்றன.

இதன் பொருள், ஒரே application-ன் ஒரே commit-ல் பணிபுரியும் இரு developers வெவ்வேறு வழிமுறைகளை இயக்கக்கூடும் என்பதாகும், ஏனெனில் அவர்கள் வெவ்வேறு நாட்களில் sync செய்திருக்கலாம். ஒரு தவறான agent இயக்கத்திற்குப் பிறகு, "எந்தப் பதிப்பு இந்தத் திறனை உருவாக்கியது?" என்ற முக்கியமான கேள்விக்கு உங்களால் பதிலளிக்க முடியாது என்பதையும் இது குறிக்கிறது. பதிவு செய்யப்பட்ட திருத்தம் (revision) இல்லையெனில், அந்த இயக்கத்தை மீண்டும் உருவாக்க முடியாது (reproducible), எனவே அந்த bug report-ன் மீது எந்த நடவடிக்கையும் எடுக்க முடியாது.

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

ஒரு திறனுக்கு (skill) compiler கிடையாது. இது ஒரு model-ஐ நோக்கிய அறிவுறுத்தல்களின் தொகுப்பு என்பதால், கோப்பின் உள்ளடக்கம் மாறாமல் இருந்தாலும் அது செயல்படுவதை நிறுத்தக்கூடும். ஒரு model மேம்படுத்தப்படும்போது, நீண்ட அறிவுறுத்தல்களை அது பின்பற்றும் விதம் மாறலாம். அந்தத் திறன் அழைக்கும் ஒரு command line tool தனது flag-ஐ மாற்றலாம். ஒரு reference கோப்பில் உள்ள URL 404 பிழையைத் தரத் தொடங்கலாம், அப்போது அந்த agent பிழைப் பக்கத்திலிருந்தே தகவல்களைச் சேகரிக்கத் தொடங்கும்.

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

2026-ல் வெளியாகும் கருவிகள் தீர்க்கும் சிக்கல்கள்

தற்போது பல தீர்வுகள் முன்வைக்கப்படுகின்றன, ஆனால் பதிப்பு (version) எங்கு இருக்க வேண்டும் என்பதில் கருத்து வேறுபாடுகள் உள்ளன.

Lockfiles. Vercel Labs-ன் skills கட்டளை வரி கருவி (vercel-labs/skills, MIT உரிமம், 5 ஆகஸ்ட் 2026 நிலவரப்படி v1.5.22) git களஞ்சியத்திலிருந்து உங்கள் agent எதிர்பார்க்கும் கோப்பகத்திற்கு (directory) skills-ஐ நிறுவுகிறது. இது எழுபதுக்கும் மேற்பட்ட agent-களின் அமைப்பை அறியும் திறன் கொண்டது. npx skills add <repo> நிறுவுவதற்கும், npx skills update மேம்படுத்துவதற்கும், npx skills list உங்களிடம் உள்ளவற்றைப் பார்ப்பதற்கும் பயன்படுகிறது. நிறுவப்பட்டவற்றின் பதிவு ஒவ்வொரு களஞ்சியத்திற்கும் தனித்தனியாக இல்லாமல், பயனர் ஒருவருக்கு ஒருமுறை என பராமரிக்கப்படுகிறது. அந்தத் திட்டத்தில் உள்ள ஒரு கோரிக்கை (issue 283), lock கோப்பிலிருந்து கண்காணிக்கப்படும் அனைத்து skills-ஐயும் மீண்டும் நிறுவும் skills install கட்டளையைக் கேட்கிறது; இதன் மூலம் இரண்டாவது கணினியிலும் அதே தொகுப்பைப் பெற முடியும். அந்தக் கோரிக்கையை ஒரு நிலை அறிக்கையாகக் கருதலாம். Lockfile குறித்த கருத்து முடிவாகிவிட்டது. அதன் தலா-திட்ட (per-project) பகுதி இன்னும் உருவாக்கப்பட்டு வருகிறது.

Specs மற்றும் சோதனைகள். SkillSpec மற்றொரு கோணத்தை எடுக்கிறது. இது SKILL.md-ஐ நம்பகமான உரைக்கு பதிலாக சரிபார்க்க வேண்டிய ஒப்பந்தமாக கருதுகிறது. skills-ஐ "பின்பற்றக்கூடியதாகவும், சோதிக்கக்கூடியதாகவும், நிரூபிக்கக்கூடியதாகவும்" மாற்றுவதே இதன் நோக்கம். skillspec doctor <path> ஒரு agent எங்கு இழையை (thread) கைவிட வாய்ப்புள்ளது என்பதைத் தெரிவிக்கிறது. skillspec boundary map <path> ஒரு skill எதை அடைய முடியும் என்பதை அறிக்கையிடுகிறது, மேலும் skillspec boundary assess <path> அந்த முடிவுகளை அபாயத்தின் அடிப்படையில் வரிசைப்படுத்துகிறது. இது Rust மொழியில் எழுதப்பட்ட crate ஆகும், இது MIT அல்லது Apache 2.0 உரிமத்தில், 29 ஜூலை 2026 நிலவரப்படி 0.2.2 பதிப்பில் உள்ளது. புதிய பதிப்பிற்குப் பதிலாக, குறிப்பிட்ட பதிப்பை (pinned version) நிறுவவும்:

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

--locked, அந்த crate வெளியிடப்பட்டபோது இருந்த dependency பதிப்புகளுடன் கட்டமைக்கிறது, எனவே build மாறாது. skillspec --version கட்டளை 0.2.2 என்று அச்சிட வேண்டும். வேறு எண் வந்தால், உங்கள் PATH-ல் உள்ள பழைய binary முன்னுரிமை பெறுகிறது என்று அர்த்தம்.

Vendor நடைமுறைகள். google/skills-ல் உள்ள skills எவ்வாறு கட்டமைக்கப்படுகிறது என்பதை agent skills-ஐ எவ்வாறு உருவாக்குவது, சோதிப்பது மற்றும் அளவிடுவது என்ற பதிவில் Google விவரித்துள்ளது. அளவீட்டைத் தவிர்த்துப் பார்த்தால், இதன் நுட்பம் சாதாரண continuous integration (CI) ஆகும். ஒவ்வொரு skill-ம் இணைக்கப்படுவதற்கு முன்பு frontmatter metadata, வரி எண்ணிக்கை, கோப்பக அமைப்பு மற்றும் பெயரிடுதல் ஆகியவற்றிற்கான linters சோதனைகளைத் தாண்ட வேண்டும். 404 பிழையைத் தரும் எந்தவொரு URL-ம் build-ஐத் தோல்வியடையச் செய்யும், இது agent உருவாக்கிய போலியான இணைப்புகளைக் கண்டறிய உதவுகிறது. ஆசிரியர்கள் skill-உடன் மதிப்பீட்டு prompt தொகுப்பு மற்றும் மதிப்பெண் அளவுகோல்களை வழங்க வேண்டும். திட்டமிடப்பட்ட மதிப்பீட்டுப் பணிகள் வாரந்தோறும் முழு நூலகத்திலும் இயங்கி, தரம் குறைவதைக் கண்டறியும். ஒவ்வொரு skill-க்கும் ஒரு உரிமையாளர் உள்ளார், தரம் குறையும் போது அவர் அதைச் சரிசெய்ய வேண்டும்.

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

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

1. ஒரே உண்மை ஆதாரம் (One source of truth). ஒரு திறமைக்கு (skill) ஒரே ஒரு இருப்பிடம் மட்டுமே இருக்கும். ஒவ்வொரு repository-யும் நகலை வைத்திருப்பதற்குப் பதிலாக, அந்த முதன்மை இருப்பிடத்தையே குறிப்பிடும்.
2. ஒவ்வொரு repository-க்கும் ஒரு pinned version. ஒவ்வொரு project-ம் தான் பயன்படுத்தும் துல்லியமான revision-ஐப் பதிவு செய்யும். எனவே, மேம்படுத்துதல் (upgrading) என்பது அந்த project-ல் ஒரு commit-ஆக அமையும், அதற்கு ஒரு ஆசிரியர் மற்றும் தேதி இருக்கும்.
3. ஒவ்வொரு திறமைக்கும் ஒரு smoke test. அந்தத் திறமை தான் உறுதியளித்த முடிவைத் தருகிறது என்பதை நிரூபிக்கும் ஒரு இயங்கக்கூடிய சோதனை.
4. ஒரு ஆய்வுப் பாதை (Review path). பகிரப்பட்ட திறமையில் செய்யப்படும் மாற்றம் ஆய்வுக்கு உட்படுத்தப்படும். ஒவ்வொரு பயனர் (consumer) அந்த மாற்றத்தை ஏற்றுக்கொள்வதற்கு முன்பு, அதற்கான diff-ஐப் பார்க்க முடியும்.

இதுவே ஒரு dependency-ன் வடிவம். கருவிகள் (tooling) உருவாவதற்கு முன்பே திறமைகள் பகிரப்பட்ட artifact-களாக மாறிவிட்டன. எனவே, நீங்கள் ஏற்கனவே நம்பும் கருவிகளே இதைப் பயன்படுத்துவதற்கு மிகவும் பாதுகாப்பானவை.

சுய-வழங்கப்பட்ட (self-hosted) git remote-ல் சிறிய குழுவிற்கான கட்டமைப்பு

ஒரு repository-ல் மட்டுமே திறன்கள் (skills) சேமிக்கப்படுகின்றன. இதில் வேறு எந்தக் கோப்புகளும் இருக்காது, எனவே இதன் வரலாறு அறிவுறுத்தல்களின் மாற்றப் பதிவாக (changelog) அமையும்.

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

Releases என்பவை tags ஆகும். Annotated tags-ஐப் பயன்படுத்தவும், ஏனெனில் அவை செய்தியையும் தேதியையும் கொண்டிருக்கும். ஒரு பயனர் ஏன் இந்த பதிப்பை மேம்படுத்த வேண்டும் என்பதற்கான காரணத்தை அந்தச் செய்தியில் குறிப்பிடவும்:

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 மூலம் Pinning செய்தல்

ஒரு submodule, மற்றொரு repository-ன் ஒரு குறிப்பிட்ட commit-ஐ உங்கள் repository-க்குள் பதிவு செய்கிறது. அந்தப் பதிவே 'pin' எனப்படும். இதைப் பயன்படுத்தும் ஒவ்வொரு திட்டத்திலும்:

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 முக்கியமானது. திட்டத்தின் மட்டத்தில் உள்ள ஒரு skill entry, வட்டில் (disk) வேறொரு இடத்தில் உள்ள directory-க்கான symlink-ஆக இருக்கலாம். Claude Code அதைப் பின்தொடர்ந்து, இலக்கு இடத்திலிருந்து SKILL.md-ஐ வாசிக்கும். எனவே, அந்த bytes நீங்கள் தேர்ந்தெடுத்த commit-ல் உள்ள submodule-ல் இருந்தாலும், அது ஒரு சாதாரண project skill போலவே ஏற்றப்படும்.

Pin-ஐச் சரிபார்க்கவும்:

git submodule status

சரியான வரி ஒரு space-உடன் தொடங்கி, பின் commit, அதன் பின் path, இறுதியாக அருகிலுள்ள tag ஆகியவற்றைக் கொண்டிருக்கும்:

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

தொடக்கத்தில் - இருந்தால், submodule இன்னும் initialise செய்யப்படவில்லை என்று பொருள். இதனால் .claude/skills/api-review எதையும் சுட்டிக்காட்டாது மற்றும் அந்த skill எந்த அறிவிப்பும் இன்றி ஏற்றப்படாது. இதைச் சரிசெய்ய git submodule update --init-ஐப் பயன்படுத்தவும். தொடக்கத்தில் + இருந்தால், தற்போது checkout செய்யப்பட்ட commit, பதிவு செய்யப்பட்ட commit-லிருந்து மாறுபடுகிறது என்று பொருள். அதாவது, அந்த developer மற்றவர்களுக்கு இல்லாத instructions-ஐ இயக்குகிறார். புதிய clone-களுக்கு git clone --recurse-submodules தேவைப்படுகிறது. இந்த வரி README-ல் இருக்க வேண்டும், ஏனெனில் சாதாரண clone மூலம் vendor/agent-skills காலியாகவே இருக்கும் மற்றும் எந்தப் பிழையும் காட்டப்படாது.

Upgrading என்பது திட்டமிட்டுச் செய்யப்பட வேண்டிய ஒன்று, அதுவே இதன் முக்கிய நோக்கமாகும்:

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 வரி என்பது review path ஆகும். இது மற்ற அனைத்து repository-களும் காணும் அதே மாற்றத்தைக் காட்டுகிறது, மேலும் இது ஒரு pull request-க்குள் அடங்கும்.

அதற்கு பதிலாக plugin marketplace மூலம் pinning செய்தல்

ஒவ்வொரு developer-ஐயும் submodules கற்கச் சொல்வதற்குப் பதிலாக, Claude Code plugin அமைப்பு உங்களுக்காக விநியோகத்தைச் செய்கிறது. இது 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 எங்கிருந்து பெறப்படுகிறது என்பது, branch அல்லது tag-க்கு ref-ஐ ஏற்கும், ஆனால் sha-ஐ ஏற்காது. Catalog-க்குள் இருக்கும் ஒரு plugin source இரண்டையுமே ஏற்கும். இவை இரண்டும் அமைக்கப்பட்டிருக்கும்போது, sha தான் இறுதியான pin-ஆகச் செயல்படும். எனவே, exact-commit pin என்பது catalog entry-ல் இருக்க வேண்டும்.

ஒவ்வொரு consuming repository-யும் தனது committed .claude/settings.json-ல் marketplace-ஐக் குறிப்பிட வேண்டும்:

{
  "extraKnownMarketplaces": {
    "acme-agents": {
      "source": {
        "source": "url",
        "url": "https://git.example.com/team/agent-skills.git",
        "ref": "v1.4.0"
      }
    }
  },
  "enabledPlugins": {
    "team-skills@acme-agents": true
  }
}

Project folder-ஐ நம்பும் ஒரு சக பணியாளருக்கு marketplace-ஐ install செய்யுமாறு prompt காட்டப்படும். Wiki பக்கம் எதையும் பார்க்காமலேயே அவர்களுக்கு plugin enabled செய்யப்படும். Skills-கள் /team-skills:api-review-க்கு பதிலளிக்கும், ஏனெனில் plugin skills-கள் plugin பெயரால் namespaced செய்யப்படுகின்றன. இதனால் ஒரே பெயரில் உள்ள project skill-உடன் இவை மோதிக்கொள்ளாது. நீங்கள் புதிய tag-ஐ push செய்த பிறகு, பயனர்கள் /plugin marketplace update acme-agents மூலம் refresh செய்ய வேண்டும், பின்னர் install summary கேட்டால் /reload-plugins-ஐ இயக்க வேண்டும்.

ஒரு திறனுக்கான smoke test எழுதுதல்

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

#!/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 என்பது ஒரு திட்டமிட்ட பிழையைக் கொண்ட சிறிய கோப்பாகும். அந்தத் திறன் அந்தப் பிழையைக் கண்டறிந்து பெயரிட வேண்டும் என்பதே assertion ஆகும். அதன் filter null-ஐ உருவாக்கும்போது jq -e non-zero exit code-ஐ அளிக்கிறது, எனவே அந்தப் பிழையைக் கண்டறிவதை நிறுத்தும் திறன் இந்த script-ஐத் தோல்வியடையச் செய்யும். இயக்கம் தோல்வியடையும் போது claude தானாகவே non-zero exit code-ஐ அளிக்கிறது, மேலும் set -euo pipefail இந்த இரண்டு தோல்விகளையும் ஒரு தோல்வியுற்ற சோதனையாக மாற்றுகிறது.

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

CI-ல், --bare-ஐச் சேர்க்கவும். அது இல்லையென்றால், claude -p ஆனது interactive session-ல் இருப்பது போன்ற அதே சூழலை ஏற்றும்; இதில் hooks, plugins மற்றும் அந்த machine-ல் உள்ள CLAUDE.md ஆகியவையும் அடங்கும், எனவே ஒரு சக ஊழியரின் தனிப்பட்ட configuration முடிவை மாற்றக்கூடும். Bare mode அனைத்து auto-discovery-ஐயும் தவிர்க்கும், அதாவது நீங்கள் சோதிக்கும் திறனையும் அது தவிர்க்கும், எனவே அதைத் தெளிவாக ஏற்றவும். 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 உடன், இயக்கத்தின் முதல் நிகழ்வு எந்தெந்த plugins ஏற்றப்பட்டன என்பதைத் தெரிவிக்கும் மற்றும் ஏற்றப்படாதவற்றுக்கு plugin_errors array-ஐக் கொண்டிருக்கும். plugin_errors காலியாக இல்லை என்றால் CI job-ஐத் தோல்வியடையச் செய்யவும். இது இனி இல்லாத ஒரு revision-ஐக் குறிக்கும் pin-ஐக் கண்டறிய உதவும், இல்லையெனில் அது agent உங்கள் விதிகளை அமைதியாகப் புறக்கணிப்பது போலத் தோன்றும்.

பகிரப்பட்ட திறன் (shared skill) என்பது ஒரு இயங்கக்கூடிய அறிவுறுத்தல்

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

முதலாவதாக, ஒரு SKILL.md, மாடல் எதையும் படிப்பதற்கு முன்பே shell கட்டளைகளை இயக்க முடியும். உடலில் உள்ள இது போன்ற ஒரு வரி preprocessing ஆகும்:

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

இந்தக் கட்டளை அந்தத் திறனை ஏற்றும் கணினியில் இயங்குகிறது, மேலும் அதன் வெளியீடு மாடல் பெறும் உரையில் உள்ள placeholder-க்கு பதிலாக அமைகிறது. மூன்று backticks-ஐத் தொடர்ந்து ! கொண்டு திறக்கப்படும் ஒரு fenced block, பல கட்டளைகளை அதே முறையில் இயக்குகிறது. இயங்கும் நேரத்தில் (run time) இதற்கு யாரும் ஒப்புதல் அளிப்பதில்லை. பகிரப்பட்ட திறனைப் படிப்பது என்பது அதன் கட்டளை மாற்றீடுகளைப் (command substitutions) படிப்பதையே குறிக்கும்.

இரண்டாவதாக, frontmatter மூலம் கருவிகளுக்கு முன்கூட்டியே ஒப்புதல் அளிக்க முடியும். allowed-tools, அந்தத் திறனை அழைக்கும் turn-க்கு எந்தவித அனுமதி வினவலும் (permission prompt) இன்றி பட்டியலிடப்பட்ட கருவிகளை வழங்குகிறது. ஒரு project skill-க்கு, அந்த folder-க்கான workspace trust dialog-ஐ ஒருவர் ஏற்றுக்கொண்டவுடன் அந்த அனுமதி நடைமுறைக்கு வரும். Claude Code ஆவணங்கள் இதன் விளைவை தெளிவாகக் கூறுகின்றன: ஒரு repository-ஐ நம்புவதற்கு முன்பு project skills-ஐ ஆய்வு செய்யுங்கள், ஏனெனில் ஒரு திறன் தனக்குத்தானே விரிவான கருவி அணுகலை வழங்கிக்கொள்ள முடியும்.

எனவே, ஒரு திறன் மேம்பாட்டை (skill bump) ஒரு dependency மேம்பாட்டைப் போலவே கையாளுங்கள். வழிமுறை அனுமதிக்கும் இடங்களில் துல்லியமான commit மூலம் pin செய்யுங்கள், ஏனெனில் ஒரு tag-ஐ மாற்ற முடியும் மற்றும் ஒரு branch என்பது வரையறைப்படி நகரும் தன்மை கொண்டது. பாதுகாக்கப்பட்ட கணினியில், settings-ல் உள்ள "disableSkillShellExecution": true, அனைத்து கட்டளை மாற்றீடுகளையும் இயக்குவதற்குப் பதிலாக [shell command execution disabled by policy] என்ற literal உரையால் மாற்றுகிறது. இதை managed settings மூலம் செயல்படுத்தினால், பயனர் அதை மீற முடியாது. Bundled மற்றும் managed திறன்கள் இந்த அமைப்பிலிருந்து விலக்கு அளிக்கப்பட்டுள்ளன.

ஒரு திறன் எதைப் படிக்கிறது என்பதிலும் அதே கவனம் தேவை. env-ஐ இயக்கும் அல்லது ஒரு config கோப்பைத் திறக்கும் ஒரு திறன், தான் கண்டெடுத்த எதையும் மாடலின் context-க்குள் கொண்டு வரும். இது நீங்கள் இயக்கும் முகவர்களிடமிருந்து ரகசியங்களை விலக்கி வைத்தல் பகுதியில் விவரிக்கப்பட்டுள்ள தோல்வியாகும். ஒரு பக்கத்தை fetch செய்யும் அல்லது ஒரு query-ஐ இயக்கும் திறன், அதே வெளிப்பாட்டை வெளிப்புறமாகச் செலுத்துவதாகும். ஏனெனில், பெறப்பட்ட உரை நீங்கள் எழுதிய அறிவுறுத்தல்களைப் போலவே context-ல் அமர்கிறது. நீங்கள் இணையத் தேடலுக்கு உங்கள் சொந்த SearXNG instance-ஐ ஒரு முகவரிடம் சுட்டிக்காட்டுவதற்கு முன்பு, இந்த எல்லையைப் பற்றிப் படிப்பது அவசியம்.

பதிப்பு மாற்றத்தின் போது கவனிக்க வேண்டியவை

• ஒவ்வொரு SKILL.md பகுதியின் diff-ஐயும் கவனிக்கவும், ஏனெனில் அந்த உரைதான் உங்கள் ஏஜென்ட் பின்பற்ற வேண்டிய அறிவுறுத்தலாகும்.
• ஒவ்வொரு command substitution-ஐயும் கவனிக்கவும், ஏனெனில் skill ஏற்றப்படும்போது அவை உங்கள் கணினியில் இயங்கும்.
• allowed-tools-ல் செய்யப்படும் எந்த மாற்றத்தையும் கவனிக்கவும், ஏனெனில் அந்த வரி எந்தவிதமான தூண்டுதலும் (prompt) இன்றி கருவிகளுக்கான அனுமதியை வழங்குகிறது.
• அந்த tag-க்கு பின்னால் உள்ள test run-ஐச் சரிபார்க்கவும். பகிரப்பட்ட repository அதன் சொந்த smoke tests-ஐ CI-ல் இயக்கினால், நீங்கள் இணைக்கும் (pinning) tag-க்கு பச்சை நிறத்திலான (green run) முடிவு இருப்பதை உறுதி செய்யவும்.

பத்து நிமிடங்களுக்குள் முழு diff-ஐயும் படிக்க முடியாத ஒரு மதிப்பாய்வாளர், மிகப்பாரியதாக வளர்ந்துவிட்ட ஒரு skill-ஐப் பார்க்கிறார் என்று அர்த்தம். அதைச் சிறு பகுதிகளாகப் பிரிக்கவும். உங்கள் ஏஜென்ட்கள் படிக்கும் repository ஆவணங்களுக்கும் இதே வாதம் பொருந்தும்: நிலையான விதிகளை AGENTS.md மற்றும் HUMAN.md பிரிப்பு என்பதில் விவரிக்கப்பட்டுள்ள கோப்புகளில் வைத்திருக்கவும், கட்டமைப்பு சார்ந்த காரணங்களை ஏஜென்ட்களுக்காக எழுதப்பட்ட DESIGN.md என்பதில் வைத்திருக்கவும், மேலும் skills-ஐ குறுகிய செயல்முறைகளாக மட்டும் வைத்திருக்கவும்.

ஒரு model அல்லது tool மாற்றத்தால் skill செயலிழக்கும்போது

எந்த மாற்றமும் செய்யப்படாத நிலையிலும், ஒரு skill-ன் பின்னணியில் பல விஷயங்கள் மாறக்கூடும். ஒரு model மேம்படுத்தப்படும்போது, நீண்ட அறிவுறுத்தல்களைப் பின்பற்றும் அதன் நம்பகத்தன்மை மாறலாம்; இதனால் ஒன்பதாவது படி வரை சரியாகச் செயல்பட்ட ஒரு skill, அந்த நிலையை எட்டாமல் போகலாம். ஒரு command line tool-ல் flag பெயர் மாற்றப்பட்டால், agent பழைய flag-ஐ இயக்கி, பிழையைப் படித்துவிட்டு, தானாகவே மாற்று வழியைத் தேடும். குறிப்பிடப்பட்ட URL 404 பிழையைத் தரலாம். ஒரு agent harness, skill-களைத் தேர்ந்தெடுக்கும் முறை மாறினால், முன்பு வெற்றி பெற்ற ஒரு description இனி வெற்றி பெறாமல் போகலாம்.

இதனால்தான் இந்த அமைப்பில் smoke test மிக முக்கியமானது. ஒவ்வொரு skill-ன் சோதனையையும் push செய்யும்போது மட்டுமல்லாமல், ஒரு கால அட்டவணைப்படியும் இயக்க வேண்டும். இதற்காகவே Google தனது முழு library-க்கும் வாராந்திர மதிப்பீட்டுப் பணிகளை (evaluation jobs) இயக்குகிறது. பத்து skill-களைக் கொண்ட ஒரு குழுவிற்கு, ஒரு சிறிய VPS-ல் வாராந்திர cron job இயக்குவதே போதுமானது. ஒரு developer அறிவதற்கு முன்பே, இந்தச் சிக்கலை நீங்கள் கண்டறிய இதுவே ஒரே வழி.

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

FAQ

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

அந்த skill-ஐ ஒரு தனி git repository-ல் வைத்து, அதில் releases-க்கு tag இடவும். கோப்புகளை நகலெடுப்பதற்குப் பதிலாக, ஒவ்வொரு project-லும் ஒரு குறிப்பிட்ட tag-ஐ reference செய்யவும். இதற்கு இரண்டு வழிகள் உள்ளன. ஒரு git submodule துல்லியமான commit-ஐப் பதிவு செய்யும்; .claude/skills/<name>-லிருந்து அந்த submodule-க்கு ஒரு symlink உருவாக்குவதன் மூலம், அது ஒரு சாதாரண project skill போல இயங்கும். ஒரு plugin marketplace, /plugin மூலம் இதே வேலையைச் செய்கிறது; இதற்கான pin, அந்த project-ன் .claude/settings.json-ல் குறிப்பிடப்பட்டிருக்கும். இவை இரண்டுமே version-ஐ git history-ல் வைப்பதால், ஒரு குறிப்பிட்ட agent run-க்கு எந்தெந்த instructions பயன்படுத்தப்பட்டன என்பதை உங்களால் கண்டறிய முடியும்.

ஒரு agent skill-ஐ குறிப்பிட்ட version-க்கு pin செய்ய முடியுமா?

SKILL.md-க்குள் இருந்து இதைச் செய்ய முடியாது, ஏனெனில் அந்த frontmatter-ல் version என்ற key கிடையாது. அந்த கோப்பைச் சுற்றியுள்ள layer-லிருந்துதான் pin செய்யப்பட வேண்டும். ஒரு git submodule வடிவமைப்பிலேயே துல்லியமான commit-ஐ pin செய்கிறது. Claude Code plugin marketplace-ல், ஒரு plugin source-ஆனது branch அல்லது tag-க்கு ref-ஐயும், துல்லியமான commit-க்கு sha-ஐயும் ஏற்கும். இவை இரண்டுமே இருக்கும்போது sha முன்னுரிமை பெறும். Marketplace source-ஆனது ref-ஐ மட்டுமே ஏற்கும். நீங்கள் review செய்த பிறகு ஒரு tag மாற்றப்படலாம் என்பதால், commit pin-ஐப் பயன்படுத்துவதே சிறந்தது.

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

நிலையான ஒன்றின் மீது சோதனையைச் செய்யவும். ஒரு அறியப்பட்ட fault-ஐக் கொண்ட fixture-க்கு எதிராக, non-interactive முறையில் அந்த skill-ஐ இயக்கவும். பின்னர், output-ல் ஒரு குறிப்பிட்ட identifier வருகிறதா என்று பார்க்கவும் (உதாரணமாக, அந்த skill கண்டறிய வேண்டிய rule id). --output-format json மற்றும் --json-schema மூலம் structured output-ஐக் கோருவது சோதனையைத் துல்லியமாக்கும்; அந்த மதிப்பு இல்லையென்றால் jq -e அந்த script-ஐத் தோல்வியடையச் செய்யும். முழு வாக்கியத்தையும் வைத்துச் சோதிக்க வேண்டாம், ஏனெனில் ஒவ்வொரு முறை இயக்கும்போதும் model தனது பதில்களை மாற்றக்கூடும்.

மற்றொரு குழுவின் repository-லிருந்து பகிரப்பட்ட skill-ஐ நிறுவுவது பாதுகாப்பானதா?

இதை ஒரு code dependency-ஆகக் கருதவும், ஏனெனில் இது இயங்கக்கூடிய instruction ஆகும். ஒரு SKILL.md, ! command substitution வடிவம் மூலம் load ஆகும்போது shell commands-ஐ இயக்க முடியும். மேலும், frontmatter allowed-tools field, prompt இல்லாமலேயே கருவிகளை முன்கூட்டியே அங்கீகரிக்க (pre-approve) முடியும். ஒவ்வொரு பதிப்பு மாற்றத்தின்போதும் (bump) diff-ஐப் படிக்கவும், branch-க்கு பதிலாகத் துல்லியமான commit-க்கு pin செய்யவும், உங்கள் குழுவின் கட்டுப்பாட்டில் உள்ள source-ஐப் பயன்படுத்தவும். நிர்வகிக்கப்படும் கணினிகளில் (managed machines), settings-ல் உள்ள "disableSkillShellExecution": true, command substitutions இயங்குவதை முழுமையாகத் தடுக்கும்.

பகிரப்பட்ட skill, Claude Code தவிர பிற agent-களில் இயங்குமா?

இது நீங்கள் பயன்படுத்தும் frontmatter-ஐப் பொறுத்தது. Agent Skills spec ஆறு keys-ஐ வரையறுக்கிறது: name, description, license, compatibility, metadata மற்றும் allowed-tools. இந்த keys-க்கு உட்பட்ட ஒரு skill, அந்த spec-ஐச் செயல்படுத்தும் அனைத்து கருவிகளிலும் இயங்கும்; அது Claude Code-லும் எந்த மாற்றமும் இன்றி இயங்கும். அந்த spec-க்கு அப்பாற்பட்ட harness-specific keys மற்றும் body அம்சங்கள் பிற இடங்களில் புறக்கணிக்கப்படும் அல்லது நிராகரிக்கப்படும். எனவே, பரவலாகப் பகிர விரும்பும் எந்தவொரு skill-லும் அவற்றைச் சேர்க்க வேண்டாம்.