SSD Nodes Learn Hosting plans →
Посібники Matt ConnorВід Matt Connor

Як синхронізувати skills агента між репозиторіями

Копії skill у восьми репозиторіях неминуче розходяться. Дізнайтеся, як винести їх у спільний репозиторій, закріпити версію та перевіряти оновлення.

Як спільно використовувати навички агентів у різних репозиторіях

Щоб спільно використовувати навички агентів у різних репозиторіях, припиніть копіювати файл і почніть робити на нього залежність. Зберігайте один репозиторій навичок, створюйте для нього тег, а в кожному проєкті фіксуйте потрібний тег. Потім додайте smoke test для кожної навички й перевіряйте кожне оновлення так само, як оновлення залежності.

Це складається з чотирьох частин: спільного джерела істини, зафіксованої версії для кожного репозиторію, smoke test для кожної навички та процесу перевірки. Нижче пояснюється, навіщо потрібна кожна частина, як інструменти, що випускаються у 2026, працюють із цим і як побудувати всю схему на self-hosted git remote без використання зовнішнього git host або package registry. Smoke tests є єдиним винятком. Вони запускають Claude Code, який надсилає кожен запит до model API, тому цей крок усе ще залишає ваш сервер.

Навичка агента — це папка, що містить файл SKILL.md, а також потрібні їй скрипти та довідкові файли. Якщо цей компонент для вас новий, спочатку прочитайте що таке навичка агента і як працює SKILL.md. Ця сторінка присвячена ланцюжку постачання для цього компонента.

Де зберігається skill і чому ним складно ділитися

Claude Code завантажує skills із чотирьох місць, а в документації skills наведено кожен шлях.

  • .claude/skills/<skill-name>/SKILL.md у каталозі керованих налаштувань — це корпоративне розташування. Skill завантажується для кожного користувача на комп’ютерах, де його розгортає організація.
  • ~/.claude/skills/<skill-name>/SKILL.md — персональне розташування. Skill завантажується в усіх ваших проєктах і не завантажується в проєктах інших користувачів.
  • .claude/skills/<skill-name>/SKILL.md — рівень проєкту. Skill завантажується для всіх, хто клонує цей репозиторій.
  • <plugin>/skills/<skill-name>/SKILL.md постачається всередині plugin. Skill завантажується всюди, де ввімкнено цей plugin.

Для команди корисним є розташування рівня проєкту, оскільки його додають до репозиторію, і кожен, хто клонує репозиторій, отримує цей skill. Водночас саме тут починаються проблеми. Skill у .claude/skills/ належить одному репозиторію. У вас є вісім репозиторіїв. Отже, skill копіюється вісім разів.

Frontmatter не допомагає. Специфікація Agent Skills дозволяє шість ключів, а шляхи розповсюдження, які її забезпечують, виводять цей список, якщо використати інший ключ:

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

Зверніть увагу, чого в цьому списку немає: ключа version. Файл не містить даних про те, яка копія є новішою. Це логічно, оскільки skill є документом, а не пакетом. Однак версії потрібно контролювати на рівні, що оточує файл, і цим рівнем маєте керувати ви.

Проблема 1: вісім копій, які непомітно розходяться

Копіювання та вставлення працює в перший день. На шістдесятий день воно вже дає збій. Хтось виправляє неправильну інструкцію в репозиторії payments, але не змінює інші сім копій. Хтось інший додає правило щодо пагінації в orders. Тепер одна й та сама назва skill дає різні результати перевірки залежно від того, з якого каталогу запустився агент, і жоден розробник про це не знає.

Збій непомітний, оскільки стану помилки немає. Skill — це текст. Застаріла інструкція призводить до впевненої, але неправильної відповіді, а саме такі помилки обходяться найдорожче. Агент не порівнює вашу копію з копіями в інших репозиторіях, тому єдиний сигнал — людина має помітити, що два репозиторії не узгоджуються.

Проблема 2: версію не зафіксовано

Навіть якщо команда зберігає навички в одному місці, зазвичай їх поширюють через крок копіювання: setup-скрипт, рядок curl у документі з інструкціями для онбордингу або shell-аліас, який синхронізує каталог. Усі ці способи встановлюють поточний стан гілки без фіксації версії.

Через це два розробники можуть працювати з одним і тим самим комітом одного застосунку, але використовувати різні інструкції, якщо вони виконали синхронізацію в різні дні. Також після невдалого запуску агента неможливо відповісти на важливе запитання: яка версія навички це спричинила? Без записаної ревізії запуск неможливо відтворити, тому звіт про помилку не дає змоги виконати діагностику.

Проблема третя: ніхто не знає, чи навичка досі працює

Навичка не має компілятора. Це інструкції для моделі, тому вона може перестати працювати, хоча файл залишиться ідентичним до останнього байта. Оновлення моделі змінює те, наскільки точно вона дотримується довгих інструкцій. Інструмент командного рядка, який викликає навичка, перейменовує прапорець. URL у довідковому файлі починає повертати 404, і агент працює зі сторінкою помилки.

У жодному з цих випадків не виникає явної помилки. Агент і далі відповідає. Просто відповідь стає гіршою, ніж минулого місяця, а це важко помітити, якщо перевіряти зміни по одному pull request.

Що вирішують інструменти, випущені у 2026 році

Кілька відповідей уже доступні, і вони по-різному визначають, де має зберігатися версія.

Lockfiles. Інструмент командного рядка skills від Vercel Labs (vercel-labs/skills, ліцензія MIT, v1.7.2 станом на 9 жовтня 2026 року) встановлює skills із git-репозиторію в каталог, якого очікує ваш агент, і знає структуру для понад сімдесяти агентів. npx skills add <repo> встановлює, npx skills update оновлює, а npx skills list показує встановлені компоненти. Інструмент підтримує два lock-файли. Глобальний файл у ~/.agents/.skill-lock.json фіксує те, що встановив один користувач. Починаючи з v1.4.1 (20 лютого 2026 року), встановлення в межах проєкту також записує skills-lock.json у корені проєкту, а вихідний код інструмента вказує, що цей файл призначений для додавання до системи контролю версій. npx skills experimental_install відновлює skills проєкту з цього файлу. Відкрите запитання в цьому проєкті (issue 283) досі стосується команди skills install, яка повторно встановлює кожен skill із глобального lock-файлу, щоб на іншій машині отримати той самий особистий набір. Розглядайте обидва файли як звіт про поточний стан. Lock-файл для окремого проєкту вже існує. Команда для відновлення з нього досі позначена як експериментальна.

Специфікації та тести. SkillSpec використовує інший підхід. Він розглядає SKILL.md як контракт, який потрібно перевіряти, а не як текст, якому слід довіряти. Заявлена мета — зробити skills «такими, яких можна дотримуватися, тестувати й доводити». skillspec doctor <path> показує, де агент, імовірно, втратить контекст. skillspec boundary map <path> показує вміст skill, а skillspec boundary assess <path> звітує, до чого він може отримати доступ, із ранжуванням за ризиком. Це Rust crate із подвійною ліцензією MIT або Apache 2.0. Версію 0.2.2 опубліковано 29 липня 2026 року; станом на 10 жовтня 2026 року вона залишається найновішою на crates.io. Встановлюйте зафіксовану версію, а не найновішу:

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

--locked виконує збірку з версіями залежностей, з якими було опубліковано crate, тому під час збірки версії не змінюються непомітно. skillspec --version має вивести 0.2.2. Інше число означає, що використовується старіший binary, який раніше знаходиться у вашому PATH.

Практика постачальника. Google описав, як створює skills у google/skills, у публікації про створення, тестування та масштабування agent skills. Якщо не брати до уваги масштаб, механізм є звичайним continuous integration (CI). Перед злиттям кожен skill проходить перевірки linter-ами для frontmatter metadata, кількості рядків, структури каталогів і найменування. Link checker зупиняє збірку, якщо будь-яка URL-адреса повертає 404. Це виявляє правдоподібне посилання, яке вигадав агент. Автори мають додавати до skill набір evaluation prompt-ів і scoring rubric. Планові evaluation jobs щотижня запускаються для всієї бібліотеки, щоб виявляти регресії, а кожен skill має призначеного власника, який повинен виправляти проблеми після зниження якості.

Шаблон, спільний для всіх трьох відповідей

Вам не обов’язково обирати один із цих варіантів. За ними стоїть одна структура, і звичайний git дає змогу реалізувати її повністю.

  1. Єдине джерело істини. Skill має рівно одне місце зберігання, а кожен репозиторій посилається на це джерело, не зберігаючи власну копію.
  2. Зафіксована версія для кожного репозиторію. Кожен проєкт записує точну ревізію, яку він використовує. Тому оновлення є commit у цьому проєкті із зазначеними автором і датою.
  3. Smoke test для кожного skill. Один виконуваний тест підтверджує, що skill і надалі дає обіцяний результат.
  4. Процес перевірки змін. Зміна спільного skill проходить review, а кожен споживач бачить diff перед її застосуванням.

Це і є структура залежності. Skills стали спільним артефактом швидше, ніж навколо них з’явилися відповідні інструменти, тому найнадійніше використовувати інструменти, яким ви вже довіряєте.

Структура для невеликої команди на self-hosted git remote

Один репозиторій містить інструкції. Більше в ньому нічого немає, тому його історія виглядає як журнал змін інструкцій.

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

Релізи — це теги. Використовуйте анотовані теги, оскільки вони містять повідомлення та дату. У повідомленні зазначайте причину, через яку користувачеві потрібне оновлення:

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

Якщо ваш remote — це Gitea, Forgejo, GitLab або bare repository через SSH на власному VPS, далі нічого не змінюється. Усе зводиться до git і symlink.

Фіксація версії за допомогою git submodule

Submodule записує один точний commit іншого репозиторію у вашому репозиторії. Цей запис і є зафіксованою версією. У кожному проєкті, який його використовує:

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 на рівні проєкту може бути symlink на каталог в іншому місці диска, а Claude Code переходить за ним і читає SKILL.md із цільового каталогу. Тому skill завантажується як звичайний skill проєкту, а його файли зберігаються в submodule на вибраному вами commit.

Перевірте зафіксовану версію:

git submodule status

Коректний рядок починається з пробілу, далі містить commit, шлях і найближчий tag:

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

Початковий - означає, що submodule ще не ініціалізовано, тому .claude/skills/api-review ні на що не вказує, а skill непомітно не завантажується. Виправте це за допомогою git submodule update --init. Початковий + означає, що checkout-нутий commit відрізняється від записаного, тому цей розробник працює з інструкціями, яких немає в інших. Для нових clone потрібна команда git clone --recurse-submodules. Її слід додати до README, оскільки звичайний clone залишає vendor/agent-skills порожнім і не виводить помилки.

Оновлення виконується свідомо, і саме в цьому полягає перевага такої схеми:

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 є способом перевірки змін. Він показує ті самі зміни, які побачить кожен інший проєкт, що використовує цей submodule, і добре підходить для pull request.

Замість pinning через marketplace плагінів

Якщо ви не хочете, щоб кожен розробник вивчав submodules, система плагінів Claude Code виконує розповсюдження за вас і працює із self-hosted remote. Додайте каталог у .claude-plugin/marketplace.json у репозиторії skills:

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

Тут задіяно два різні джерела, і саме їх плутання є типовою помилкою. Джерело marketplace, тобто місце, звідки отримується сам каталог, приймає ref для гілки або tag і не приймає sha. Джерело плагіна всередині каталогу приймає обидва параметри. Якщо задано обидва, ефективним pin є sha. Отже, pin на точний commit потрібно вказувати в записі каталогу. Назви типів також відрізняються. У каталозі url означає git-репозиторій для клонування. У джерелі marketplace url означає пряме посилання на файл marketplace.json, а git-репозиторій позначається як git.

Кожен репозиторій, який використовує плагін, оголошує marketplace у своєму закоміченому .claude/settings.json:

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

Claude Code реєструє marketplace для учасника команди після того, як той приймає діалог довіри до workspace для папки проєкту. Окрема сторінка у wiki для цього не потрібна. Запис каталогу містить git URL, а не відносний шлях, тому сам плагін не встановлюється лише з налаштувань репозиторію. Кожен учасник команди один раз виконує claude plugin install team-skills@acme-agents --scope project. До цього Claude Code повідомляє, що плагін увімкнено в налаштуваннях проєкту, але його не встановлено. Після цього skills доступні через /team-skills:api-review, оскільки skills плагіна мають простір імен за назвою плагіна й не конфліктують із project skill з такою самою назвою. Після публікації нового tag споживачі оновлюють дані за допомогою /plugin marketplace update acme-agents, а потім виконують /reload-plugins, якщо цього вимагає підсумок встановлення.

Написання smoke test для однієї навички

Smoke test — це запуск агента за сценарієм на fixture із відомою помилкою та однією перевіркою. Claude Code працює в неінтерактивному режимі з -p, а навичка, яку викликає користувач, працює і в цьому режимі: додайте /skill-name до рядка prompt, і його буде розгорнуто до початку запуску.

#!/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 — це короткий файл з однією навмисно внесеною помилкою. Перевірка полягає в тому, що навичка називає цю помилку. jq -e завершується з ненульовим кодом, коли його filter повертає null, тому навичка, яка перестала виявляти підготовлену помилку, призводить до збою скрипту. Сам claude завершується з ненульовим кодом, якщо запуск не вдався, а set -euo pipefail перетворює будь-яку з цих помилок на невдалий тест.

Модель по-різному формулює відповіді під час різних запусків, тому ніколи не перевіряйте повне речення. Перевіряйте ідентифікатор, який має виводити навичка, або поле схеми, яку ви запросили. Зробіть fixture невеликою, щоб запуск залишався недорогим.

У CI додайте --bare. Без нього claude -p завантажує той самий контекст, що й інтерактивний сеанс, зокрема hooks, plugins і CLAUDE.md із машини, на якій він працює. Через це особиста конфігурація іншого учасника команди може змінити результат. Bare mode пропускає автоматичне виявлення, а отже пропускає і навичку, яку ви тестуєте. Тому завантажте цю навичку явно. Bare mode також не читає облікові дані підписки, тому спочатку задайте ANTHROPIC_API_KEY в 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

Plugin, завантажений за допомогою --plugin-dir, отримує назву з .claude-plugin/plugin.json. Без цього manifest його назвою стає назва каталогу. Додайте plugin.json з "name": "team-skills" поруч із catalog у repository навичок. Інакше наведена вище команда має викликати /agent-skills:api-review.

За допомогою --output-format stream-json подія system/init повідомляє, які plugins було завантажено, і містить масив plugin_errors для тих, які не завантажилися. Подія відкриває stream, якщо перед нею не надходять startup events. Завершуйте CI job помилкою, якщо plugin_errors не порожній. Це виявляє pin, що вказує на revision, якої більше не існує. Інакше така проблема виглядає як тихе ігнорування агентом внутрішніх правил.

Спільна skill є виконуваною інструкцією

Дві функції роблять це твердження буквальним, і обидві важливі, коли файл надходить від іншої команди.

По-перше, SKILL.md може виконувати shell-команди до того, як модель прочитає будь-який текст. Такий рядок у тілі є preprocessing:

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

Команда виконується на машині, яка завантажує skill, а її вивід замінює placeholder у тексті, який отримує модель. Fenced block, відкритий трьома backticks із подальшим !, так само виконує кілька команд. Під час виконання ніхто не отримує запиту на підтвердження. Claude Code перевіряє кожну команду відповідно до ваших permission rules. Поза auto mode команда, яку ці правила не дозволяють, перериває skill, якщо skill не надає їй попереднього дозволу через другу функцію нижче. Читання спільного skill означає також читання його command substitutions.

По-друге, frontmatter може заздалегідь дозволити tools. allowed-tools надає перелічені tools без permission prompt протягом turn, який викликав skill. Workspace trust не обмежує цей дозвіл: Claude Code застосовує allowed-tools project skill навіть під час виконання -p у папці, якій ніхто не довірив. Документація Claude Code прямо зазначає наслідок: skill може самостійно надати собі широкий доступ до tools, тому перед запуском Claude Code у репозиторії перевірте allowed-tools skills, доданих до цього репозиторію. Організація може заборонити це поле для project і personal skills, задавши allowManagedPermissionRulesOnly у managed settings; для цього потрібен Claude Code v2.1.282 або новіший.

Тому оновлення skill слід обробляти так само, як оновлення dependency. Де це дозволяє механізм, фіксуйте exact commit, оскільки tag можна перемістити, а branch за визначенням змінюється. На машині з обмеженими правами "disableSkillShellExecution": true у settings замінює кожну command substitution буквальним текстом [shell command execution disabled by policy] замість її виконання; якщо це задано через managed settings, користувач не може перевизначити параметр. Bundled і managed skills не підпадають під це налаштування.

Такої самої обережності потребує і робота skill з даними. Skill, який виконує env або відкриває config file, додає до context моделі все, що знаходить. Саме цей випадок описано в як не допускати потрапляння секретів до агентів, яких ви запускаєте. Skill, який отримує сторінку або виконує query, створює таку саму exposure назовні, оскільки отриманий текст потрапляє в context і виглядає так само, як інструкції, написані вами. Про цю межу варто прочитати до того, як ви скерували агента до власного SearXNG instance для web search.

Що читати під час оновлення версії

  • Diff кожного тіла SKILL.md, оскільки цей текст містить інструкції, яких дотримуватиметься ваш агент.
  • Кожну підстановку команди, оскільки вона виконується на вашій машині під час завантаження skill.
  • Будь-яку зміну в allowed-tools, оскільки цей рядок надає інструменти без запиту.
  • Результат тестового запуску, пов’язаного з tag. Якщо спільний репозиторій запускає власні smoke-тести в CI, tag, на який ви закріплюєте версію, має мати прикріплений успішний запуск.

Якщо reviewer не може прочитати весь diff за десять хвилин, skill став надто великим. Розділіть його. Те саме стосується документів репозиторію, які читають ваші агенти: зберігайте незмінні правила у файлах, описаних у розподілі між AGENTS.md і HUMAN.md, а архітектурні обґрунтування — у DESIGN.md, написаному для агентів, і залишайте skills вузькоспеціалізованими процедурами.

Коли зміна моделі або інструмента порушує роботу skill

Під час роботи skill може змінитися багато компонентів, навіть якщо ніхто не редагує сам skill. Оновлення моделі змінює надійність виконання довгих інструкцій. Через це skill, який залежав від досягнення моделлю кроку дев’ять, може перестати до нього доходити. Утиліта командного рядка може перейменувати flag. Тоді agent запускає старий flag, читає помилку та імпровізує. URL, на який є посилання, може почати повертати 404. Agent harness може змінити спосіб вибору skill. Через це description, який раніше перемагав під час зіставлення, більше не відповідає потрібному критерію. Якщо процедура через це починає завершуватися достроково, збільшення версії не усуває проблему. Самі інструкції потрібно структурувати так, щоб вони змушували виконувати останні кроки. Саме на цьому ґрунтується skill unlazy та його метод Depth Tree.

Тому в цій схемі smoke test має вирішальне значення. Запускайте тест кожного skill за розкладом, а також після push. Google щотижня запускає свої evaluation jobs для всієї бібліотеки саме з цієї причини. Для команди з десятьма skill достатньо щотижневого cron job на невеликому VPS. Це єдиний спосіб дізнатися про проблему раніше, ніж її виявить розробник.

Переносимість також допомагає. Специфікація Agent Skills обмежує frontmatter шістьма ключами. Тому skill, написаний відповідно до цієї специфікації, завантажується в різних інструментах, а не лише в тому, для якого його створили. Кожен ключ, специфічний для певного harness, є ставкою на одного vendor. Створення skill, які працюють після заміни моделі, є окремою дисципліною. Вона розглядається в матеріалі як забезпечити роботу skill на будь-якій моделі.

FAQ

Як поширити одну навичку агента між кількома репозиторіями?

Розмістіть навичку в окремому git-репозиторії, позначайте в ньому релізи тегами, а в кожному проєкті-споживачі посилайтеся на тег замість копіювання файлу. Працюють два механізми. git submodule фіксує точний коміт, а symlink із .claude/skills/<name> до submodule дає змогу завантажувати навичку як звичайну навичку проєкту. Plugin marketplace виконує те саме завдання через /plugin, а pin оголошується в .claude/settings.json репозиторію-споживача. В обох випадках версія зберігається в історії git, тому можна визначити, які інструкції сформували конкретний запуск агента.

Чи можна зафіксувати навичку агента на певній версії?

Не всередині SKILL.md, оскільки цей frontmatter не має ключа version. Pin має надходити зі шару навколо файлу. git submodule за своєю структурою фіксує точний коміт. У plugin marketplace для Claude Code джерело плагіна приймає ref для гілки або тега та sha для точного коміту; якщо вказано обидва параметри, пріоритет має sha. Саме джерело marketplace приймає лише ref. Надавайте перевагу pin на коміт, оскільки тег можна перемістити після його перевірки.

Що має перевіряти smoke test навички?

Перевіряйте стабільний результат. Запустіть навичку в неінтерактивному режимі на fixture із відомою помилкою, а потім перевірте, чи з’явився у виводі конкретний ідентифікатор, наприклад ідентифікатор правила, який навичка має повідомити. Запит структурованого виводу за допомогою --output-format json і --json-schema робить перевірку точною, а jq -e завершує скрипт із помилкою, якщо значення відсутнє. Не перевіряйте повне речення, оскільки модель може по-різному формулювати відповіді під час різних запусків.

Чи безпечно встановлювати спільну навичку з репозиторію іншої команди?

Розглядайте її як залежність коду, оскільки вона містить виконувані інструкції. SKILL.md може виконувати shell-команди під час завантаження через форму підстановки команд !, а поле frontmatter allowed-tools може попередньо дозволяти інструменти без запиту. Перевіряйте diff під час кожного оновлення, фіксуйте залежність на точному коміті, а не на гілці, і надавайте перевагу джерелу під контролем вашої команди. На керованих машинах "disableSkillShellExecution": true у settings повністю забороняє виконання підстановок команд.

Чи працюватиме спільна навичка в агентах, відмінних від Claude Code?

Це залежить від того, які поля frontmatter ви використовуєте. Специфікація Agent Skills визначає 6 ключів: name, description, license, compatibility, metadata і allowed-tools. Навичка, обмежена цими ключами, завантажується в інструментах, що реалізують специфікацію, а також працює в Claude Code без змін. Специфічні для harness ключі та функції вмісту, що виходять за межі специфікації, в інших системах ігноруються або відхиляються. Тому не використовуйте їх у навичках, які плануєте широко поширювати.

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