Через пару месяцев после появления агентов в команде скиллы лежат в Google Docs, Notion, личных папках и десятке репозиториев. У кого-то свежая версия чек-листа код-ревью, у кого-то устаревшая. Кто и когда её менял, никто не помнит. Это знакомая история про документацию, только теперь документация исполняется агентом.
Скилл — это папка с файлом SKILL.md, инструкция для агента в открытом стандарте, который 18 декабря 2025 года опубликовала Anthropic как Agent Skills. Стандарт уже поддерживают Claude, OpenAI Codex, Gemini CLI, GitHub Copilot, Cursor и VS Code. Агент подгружает скилл, когда задача совпадает с его назначением, и расходует на это минимум контекста.
Два слоя: хранилище и установщик
Любое решение состоит из двух частей. Первая часть, хранилище или реестр, содержит каталог скиллов, версии, права доступа и историю изменений. Вторая часть, установщик, берёт скилл из реестра и раскладывает его по директориям агентов на машине сотрудника. Если у вас есть только одно из двух, проблема решена наполовину. Реестр без установщика превращается в вики, до которого никто не доберётся. Установщик без реестра становится скриптом, который тащит файлы из случайных мест.
От простого к строгому
В статье на Habr разобраны четыре варианта. Самый простой — это GitLab или GitHub плюс CLI skills от Vercel. Хранилищем служит обычный репозиторий, установщик запускается командой npx skills add
На 20–100 скиллах git-поиск справляется, дальше становится неудобно. Тогда смотрят в сторону специализированных реестров. Skilly — это self-hosted с веб-каталогом, RBAC (управление доступом по ролям) и immutable semver-версиями. SkillReg работает как облачный SaaS со встроенным поиском. Выбор между ними сводится к вопросу «своя инфраструктура или чужое облако», как и с любым другим корпоративным софтом.
Почему это работает
Внутренний npm или PyPI решает ровно ту же задачу для кода: единый каталог, версии, проверка и контроль доступа. Скиллы — это зависимости в коде, а не «просто текстовые файлы». Агент исполняет их с доверием, внутри может оказаться промпт-инъекция или вредоносный скрипт. Поэтому реестр без ревью и сканирования становится реестром уязвимостей.
Важная деталь про модель доступа. В git-схеме публиковать может любой, у кого есть права на merge в main. В Skilly публикация идёт через RBAC с разделением прав на чтение, запись и одобрение. Кто-то должен нести ответственность за то, что скилл оказался у всех. Без этой роли «никто не виноват» вернётся обратно.
Как применить
- Зафиксируйте соглашение об именовании, например skills/
/SKILL.md в корпоративном репозитории. Так проще искать скиллы и валидировать их автоматически. - Разделите роли между автором и ревьюером. Автор пишет скилл и pull request, ревьюер из CODEOWNERS одобряет merge. Только после этого изменение попадает в main.
- Подключите CI. На каждый merge прогоняйте валидацию структуры SKILL.md, security-скан содержимого и smoke-тест установки через npx skills add в чистую директорию.
- Зафиксируйте версии. После установки installer пишет lock-файл с SHA256-хешем содержимого и версией коммита. Это даёт проверку целостности и обнаружение ручных правок в обход процесса.
- При росте разнесите скиллы по репозиториям внутри группы: engineering-skills, security-skills, sales-skills. Установку из нескольких источников соберите в bootstrap-скрипт.
- Если скиллов становится много или нужен строгий контроль доступа, переходите на Skilly или SkillReg. Поиск по файлам в Git для этого перестаёт справляться.