Централизованные хранилища скиллов (Skill registries)

Централизованные хранилища скиллов для AI‑агентов: зачем они нужны и как выбрать решение

Компании всё активнее пользуются AI‑агентами: Claude Code, Cursor, Codex, Copilot. Вместе с агентами появляются и «скиллы» — инструкции, которые учат агента работать по правилам конкретной компании. Через пару месяцев оказывается, что эти скиллы лежат в Google Docs, Notion, личных папках и десятке git‑репозиториев. У кого‑то версия свежая, у кого‑то устаревшая, а проверял ли их кто‑нибудь на безопасность, никто сказать не может.

В статье разберём, что такое централизованное хранилище скиллов, какие задачи оно решает, и сравним четыре подхода к его построению: от «просто git‑репозитория» до готового SaaS. Статья рассчитана не только на разработчиков: все термины объясняются по ходу, а для менеджеров, аналитиков и специалистов по ИБ есть словарик и раздел «как выбрать».

TL;DR

• Скилл — это папка с файлом SKILL.md: инструкция для AI‑агента в открытом стандарте, который поддерживают основные агенты.

• Централизованное хранилище скиллов для AI‑инструкций играет ту же роль, что внутренний npm/PyPI для кода: единый каталог, версии, проверка и контроль доступа.

• Любое решение состоит из двух слоёв: хранилища (где лежат скиллы) и установщика (кто доставляет их в агентов на компьютере сотрудника).

• Разобраны четыре варианта: GitLab/GitHub + npx skills, GitLab/GitHub + RoleCraft, Skilly (self‑hosted) и SkillReg (SaaS).

• Коротко о выборе: для небольшой технической команды хватит git; если скиллов сотни или нужен строгий контроль, понадобится специализированный реестр. Выбор между Skilly и SkillReg сводится к вопросу «своя инфраструктура или чужое облако».

Что такое скилл

Если вы уже пишете скиллы, раздел можно пропустить.

Скилл — это набор инструкций, который агент подгружает, когда задача пользователя совпадает с его назначением. Например: «проводи ревью pull request по чек‑листу компании», «оформляй отчёт в фирменном стиле», «ищи информацию о клиенте в таком‑то порядке».

Формат скиллов стандартизирован. Anthropic опубликовала Agent Skills как открытый стандарт 18 декабря 2025 года, выложив спецификацию и SDK на agentskills.io, чтобы его могла использовать любая AI‑платформа. Среди платформ, поддерживающих стандарт, — Claude, OpenAI Codex, Gemini CLI, GitHub Copilot, Cursor и VS Code.

По сути, скилл — это папка с файлом SKILL.md. В нём есть метаданные (как минимум имя и описание) и инструкции для агента; рядом можно положить скрипты, справочные материалы и шаблоны.

code-review/
├── SKILL.md        # обязательный: метаданные + инструкции
├── scripts/        # опционально: исполняемый код
├── references/     # опционально: справочные материалы
└── assets/         # опционально: шаблоны, ресурсы

Минимальный SKILL.md выглядит так:

---
name: code-review
description: Ревью pull request по стандартам компании. Используй, когда пользователь просит проверить PR или diff.
---

# Code review по стандартам компании

1. Проверь, что к изменениям есть тесты.
2. Сверь именование с гайдом по стилю (см. references/style-guide.md).
3. ...

Важная деталь — экономия контекста. Полные инструкции загружаются только тогда, когда они нужны для задачи. Поэтому агент может держать под рукой много скиллов и почти не расходовать контекст. Это значит, что скиллов в компании со временем может стать очень много.

Важно для ИБ: скилл — это инструкция, которую агент выполняет с доверием. Внутри может оказаться prompt injection или вредоносный скрипт. Поэтому скилл стоит воспринимать как зависимость в коде, а не как «просто текстовый файл».

Проблема: скиллы расползаются по компании

Без единого места хранения в компании быстро складывается знакомая картина:

• Изобретение велосипедов.
  Скилл «ревью PR по стандартам компании» пишут заново в каждой команде, потому что никто не знает, что у соседей такой уже есть.

• Рассинхронизация версий.
  Хорошую доработку получают не все: кто‑то продолжает работать по устаревшей, а иногда и ошибочной версии.

• Нет ответственности.
  Никто не может ответить, кто и когда добавил скилл и проверял ли его кто‑нибудь на безопасность.

• Нетехнические сотрудники остаются в стороне.
  Если скиллы лежат только в git, пользоваться ими могут только те, кто умеет работать с git.

Что такое централизованное хранилище скиллов

Централизованное хранилище скиллов (Centralized AI Skills Registry) — это единая система хранения, версионирования и распространения переиспользуемых инструкций для AI‑агентов. Она заменяет разрозненное хранение скиллов в заметках, чатах, локальных файлах и несинхронизированных репозиториях.

Аналогия для разработчиков: хранилище делает для скиллов то же, что внутренний npm‑ или PyPI‑реестр делает для кода. Никто не пишет свою версию одной и той же функции с нуля: есть единый источник правды, откуда все берут и куда все публикуют обновления.

Какие задачи оно решает

Кому и чем это удобно

Сотруднику. Не нужно знать, где физически лежит скилл: его находят в каталоге и ставят одной командой или кнопкой. Сразу видно, какой скилл одобрен компанией, а какой ещё на модерации.

Автору скилла. Публикация превращается из «разослал файл в Slack» в отслеживаемый процесс с историей изменений. По статистике установок видно, какие скиллы действительно нужны людям.

Компании. Появляется единая точка контроля рисков. Можно в любой момент ответить на вопрос «какие AI‑инструкции сейчас используются и кем». И скилл, написанный одной командой, автоматически становится доступен остальным.

Словарик для тех, кто не пишет код

Архитектура: два слоя

Любое решение, как бы оно ни называлось, состоит из двух частей:

  Автор скилла                                                    Компьютер сотрудника
       │                                                         ┌──────────────────────┐
       │ publish       ┌───────────────────────┐    install      │  .claude/skills/     │
       └─────────────▶ │  1. Хранилище         │ ─────────────▶  │  .cursor/skills/     │
                       │  (registry)           │  2. Installer   │  .codex/skills/ ...  │
                       │  каталог, версии,     │  (CLI / App)    └──────────────────────┘
                       │  права, review, аудит │
                       └───────────────────────┘

1. Хранилище (registry) — место, где живут корпоративный каталог, версии, права доступа и история. Это может быть GitLab/GitHub или отдельный реестр.

2. Installer (package manager) — клиент, который берёт скилл из хранилища и физически кладёт его в директории агентов: Claude Code, Cursor, Codex, Copilot и других.

Рассмотренные ниже решения различаются тем, какой из слоёв они закрывают и насколько глубоко.

Обзор четырёх вариантов

Дальше — подробнее о каждом.

Вариант 1. GitLab/GitHub + npx skills

Базовая и самая простая схема. Хранилищем служит обычный git‑репозиторий, установщиком — open‑source CLI skills от Vercel. Проект позиционирует себя как CLI для открытой экосистемы агентских скиллов и заявляет поддержку OpenCode, Claude Code, Codex, Cursor и ещё нескольких десятков агентов.

Как устроено хранение

Отдельная инфраструктура не нужна: скиллы — это файлы в репозитории.

company-skills/
├── README.md
├── skills/
│   ├── code-review/
│   │   ├── SKILL.md
│   │   └── references/
│   ├── security-review/
│   │   └── SKILL.md
│   └── sales-account-research/
│       └── SKILL.md
└── .gitlab-ci.yml

Installer ищет папки с SKILL.md в типовых местах (skills/, .agents/skills/ и так далее), поэтому в корпоративном репозитории стоит договориться о простом соглашении skills/<skill-name>/SKILL.md. Так проще искать скиллы, ревьюить их и валидировать автоматически.

Установка

CLI принимает GitHub‑сокращение owner/repo, полный URL, ссылку на GitLab, любой git URL (включая SSH) и локальный путь. Для приватного корпоративного GitLab это выглядит так:

# посмотреть, какие скиллы есть в репозитории (ничего не устанавливая)
npx skills add git@gitlab.company.local:ai/company-skills.git --list

# установить конкретный скилл
npx skills add git@gitlab.company.local:ai/company-skills.git --skill code-review

# несколько скиллов за раз
npx skills add <repository> --skill code-review --skill security-review

# все скиллы из репозитория
npx skills add <repository> --skill '*'

npx запускает пакет без предварительной установки. Адрес в формате git@... означает подключение по SSH‑ключам.

Куда попадает скилл и зачем нужны symlink

Реальные файлы скилла лежат в одном месте — в каноничной директории .agents/skills/<skill> (уровень проекта) или ~/.agents/skills/<skill> (глобальный уровень). В папках конкретных агентов создаются не копии, а символические ссылки на эту копию. В итоге все агенты смотрят на одни и те же файлы, и обновление не порождает расходящихся версий.

На Windows создание symlink без прав администратора или Developer Mode часто запрещено, поэтому installer использует цепочку запасных вариантов:

1. создать symlink;

2. если не получилось — directory junction (аналог ссылки, не требующий повышенных прав);

3. если и это не сработало — скопировать файлы. Связь с каноничной копией при этом теряется.

Режим копирования можно включить и явно — флагом --copy.

Какому агенту ставить скилл, installer определяет по наличию стандартных директорий (~/.claude, ~/.cursor, ~/.codex и так далее). В CI и управляемых установках на автоопределение лучше не полагаться и указывать агентов явно:

npx skills add <repository> --skill code-review --agent claude-code --agent cursor
npx skills add <repository> --skill code-review --agent '*'   # все поддерживаемые

Lock‑файл и контроль целостности

При установке CLI вычисляет SHA256-хеш содержимого скилла и записывает его в lock‑файл вместе с источником и версией (коммитом). Принцип тот же, что у package-lock.json в npm. Это даёт:

• проверку целостности — видно, если файлы на диске изменились (случайно или злонамеренно);

• воспроизводимость — у всех установлена одна и та же версия, а не просто «скилл с таким именем»;

• обнаружение дрейфа — можно найти скиллы, которые кто‑то поправил вручную в обход штатного процесса.

Обновление и процесс публикации

npx skills update                    # всё
npx skills update code-review        # конкретный скилл
npx skills update -g                 # только глобальные

Отдельная платформа для публикации не нужна: публикация = merge в защищённую ветку. Качество обеспечивают обычные механизмы GitLab/GitHub:

git clone → новая ветка → skills/my-skill/SKILL.md → commit/push
→ Merge Request → CI (схема, security-скан, smoke-тест установки)
→ ревью CODEOWNERS → merge в main → (tag/release) → npx skills update у пользователей

Что будет при 1000 скиллов

Технически --list и --skill позволяют выбрать один скилл даже из огромного репозитория. Но упираемся в два ограничения:

1. Доставка. CLI использует shallow clone, а поддержка sparse‑checkout для больших монорепозиториев на момент исследования была открытым вопросом в трекере проекта. Поэтому выбор одного скилла не гарантирует, что по сети скачается только его папка.

2. Поиск. Дерево файлов и поиск по коду в GitLab — не каталог. На 20–100 скиллах этого хватает, на тысяче сотруднику становится неудобно.

Поэтому при росте лучше разнести скиллы по репозиториям внутри группы:

GitLab group: ai-skills/
├── engineering-skills
├── security-skills
├── data-skills
├── sales-skills
└── skills-catalog      (README / сайт / index.json)

Минус такого подхода: установить скиллы из нескольких репозиториев одной командой нельзя, на каждый источник нужен отдельный вызов add. Обычно это решают bootstrap‑скриптом, который лежит в отдельном репозитории.

Итог по варианту

Плюсы: знакомая git‑инфраструктура; ревью и история остаются в git; быстрый старт; приватный доступ по SSH/HTTPS; много поддерживаемых агентов; кроссплатформенность; минимальная привязка к вендору (обычный SKILL.md + git).

Минусы: нет полноценного UI каталога; права задаются на уровне репозитория или группы, а не отдельного скилла; нет встроенной аналитики установок; каталог приходится поддерживать самим.

Вариант 2. GitLab/GitHub + RoleCraft

RoleCraft — альтернативный установщик поверх того же git‑хранилища. Проект описывает себя как пакетный менеджер для AI‑агентов, умеющий устанавливать, тестировать и публиковать скиллы и MCP‑серверы. Это CLI без внешних зависимостей, который работает офлайн и не требует регистрации.

RoleCraft принимает источники из локальной папки, GitHub, GitLab, SSH и npm, разбирает SKILL.md, выполняет локальный security‑скан, раскладывает скилл по агентам и записывает SHA256 в lock‑файл.

rolecraft install ./my-skill --cursor --copilot
rolecraft install git@gitlab.company.local:ai/skills.git --all

Чем полезнее npx skills:

• rolecraft bundle <sources> — установка из нескольких источников одной командой;

• rolecraft check и rolecraft rollback <slug> — проверка состояния и откат на предыдущую версию;

• rolecraft verify — проверка целостности по хешу;

• security scoring — не просто вердикт «прошёл/не прошёл», а числовая оценка риска. На её основе удобно строить правила вроде «блокировать всё выше medium»;

• управление MCP‑серверами тем же инструментом.

Чего RoleCraft не даёт: он не превращает GitLab/GitHub в полноценный приватный реестр. Его каталог — публичный, общий для сообщества. Корпоративные RBAC, approval и поиск всё равно должны жить в GitLab/GitHub или другом реестре.

Вариант 3. Skilly — self‑hosted корпоративный реестр

Здесь появляется то, чего не хватало git‑схемам, — полноценный каталог. Skilly — self‑hosted реестр, который превращает скиллы организации в управляемый версионируемый актив компании; идентификация пользователей построена на Microsoft Entra ID.

Возможности

• Каталог с поиском — по ключевым словам, категориям, описанию и автору. Сотрудник узнаёт, что нужный скилл уже есть, и не делает дубликат.

• Разграничение по командам — скиллы Security видны Security, скиллы Sales видны Sales, общекорпоративные видны всем.

• Корпоративная идентификация — вход через Entra ID / OIDC, синхронизация пользователей по SCIM: уволенный сотрудник теряет доступ автоматически.

• RBAC — разработчик устанавливает, тимлид публикует скиллы команды, security‑инженер одобряет или блокирует.

• Review/approval — аналог code review для скиллов.

• Централизованный security‑скан при каждой публикации, а не только на машине пользователя.

• Immutable semver — однажды опубликованную code-review@1.2.0 изменить нельзя, исправление выходит как 1.2.1.

• Yank/revoke, журнал аудита и аналитика установок.

Как хранится и доставляется скилл

Под капотом — Postgres, объектное хранилище и собственный git smart server. Каждый скилл отдаётся как git‑репозиторий через аутентифицированный git‑сервер: один скилл — один репозиторий, каждая версия — неизменяемый тег. Токен в URL выпускается на конкретный скилл для конкретного пользователя и отзывается при удалении скилла.

Отдельный CLI пользователю не нужен: каталог выдаёт готовую команду для того же npx skills:

npx skills add \
  https://x-access-token:<token>@skilly.company.local/team-a/code-review.git#v1.2.0

Любое изменение проходит цепочку proposal → review → security scan и только потом становится новой версией. В отличие от модели «всегда тяни свежий main», production‑версия — это явно опубликованный релиз, который можно закрепить, продвинуть как рекомендуемый или отозвать.

На что обратить внимание в пилоте. Skilly отвечает за хранение и проверку, а доставку выполняет npx skills. Поэтому стоит отдельно проверить два сценария: pinned rollout (жёстко зафиксированная версия) и tracking latest (отслеживание последней версии). Во втором важно убедиться, что локальное обновление не притянет отозванную или ещё не одобренную версию.

Что придётся обслуживать

Postgres, MinIO или другое S3-совместимое хранилище, git volume, веб‑приложение, worker, ClamAV, reverse proxy, а также Docker Compose или Helm/Kubernetes. Бэкапить нужно как минимум Postgres, объектное хранилище и git volume.

Сильные стороны: настоящий приватный реестр внутри периметра; каталог, удобный при сотнях и тысячах скиллов; управление доступом сотрудников через Entra/SCIM; токены на уровне отдельного скилла; нет навязанного собственного CLI.

Вариант 4. SkillReg — готовый SaaS‑реестр

SkillReg — облачный сервис: хранилище живёт на серверах поставщика, компания заводит организацию и подключается через CLI или десктопное приложение. Продукт ориентирован на совместную работу со скиллами внутри компании: версионирование, права доступа и согласования для Claude Code, Codex, Cursor, Copilot и других агентов. Помимо CLI для разработчиков и CI/CD, есть нативное десктопное приложение, которое позволяет просматривать и устанавливать скиллы без терминала.

Внедрение

1. Регистрация организации в веб‑интерфейсе.

2. Настройка ролей: кто публикует (push), кто только устанавливает (pull), кто одобряет.

3. Установка CLI авторами скиллов:

   npm install -g @skillreg/cliskillreg login

4. Импорт существующих скиллов — из GitHub или вручную через skillreg init + skillreg push.

5. Раскатка на пользователей: CLI или десктопное приложение.

6. CI‑токены для автоматической публикации при merge в main.

Публикация

Исходники остаются в обычном git, а в реестр явно публикуются готовые релизы:

skillreg push ./code-review --bump patch    # 1.2.0 → 1.2.1
skillreg push ./code-review --bump minor    # 1.2.0 → 1.3.0
skillreg push ./code-review --dry-run       # проверить, ничего не публикуя

Для пакетной публикации есть push-all. После push версия проходит approval и только потом становится доступна для установки. Такое разделение позволяет держать черновики в git, а в реестре — только стабильные релизы. Скиллы хранятся как пакеты в неймспейсе организации (@company/code-review@1.2.0), в реестре сохраняются все версии.

Поиск и установка

skillreg search "code review"
skillreg info @company/code-review
skillreg pull @company/code-review              # latest
skillreg pull @company/code-review@1.2.0        # конкретная версия
skillreg pull @company/code-review@^1.2.0       # совместимые обновления
skillreg pull-all --org company --agent all     # вся библиотека компании разом

Нюанс с агентами.
Автоопределения установленных агентов нет. Флаг --agent принимает claude, codex, cursor или all (по умолчанию — claude), и файлы кладутся по фиксированным путям независимо от того, установлен ли агент на самом деле. Для других агентов путь придётся указать вручную через -o/--output.

Нюанс с версиями.
Повторный pull без версии всегда подтягивает latest. Если нужна стабильность, закрепляйте версию или диапазон явно.

Возможности зависят от тарифного плана; актуальные условия смотрите на сайте сервиса.

Сводное сравнение

Практические впечатления

Сухие таблицы не передают ощущений от работы, поэтому вот личные наблюдения после тестирования всех четырёх вариантов.

GitLab/GitHub + npx skills.
Быстрая загрузка и выгрузка большого количества скиллов. Но пользователю без опыта работы с git и терминалом тяжело. А --list на большом репозитории сразу вываливает весь список, например тысячу скиллов, и выбирать из него неудобно.

GitLab/GitHub + RoleCraft.
На практике мало отличается от предыдущего варианта. Главное преимущество — команда bundle.

Skilly.
Приятный интерфейс, можно обсуждать скиллы, есть система рейтинга. Совсем без терминала не обойтись, но работы в нём минимум. Загрузка большого количества скиллов медленная и неудобная. Разворачивать всё приходится самостоятельно (MinIO, Caddy, Postgres и прочее), зато контроль полный.

SkillReg.
Есть десктопное приложение, интерфейс не перегружен и понятен без инструкции. Настройка практически нулевая. Большие объёмы скиллов загружаются со средней скоростью по сравнению с остальными вариантами. Но без платной подписки использовать сервис всерьёз смысла нет.

Как выбрать

Несколько вопросов, которые стоит задать до выбора:

1. Можно ли хранить скиллы вне периметра?
   Скиллы часто содержат внутренние процессы и знания компании. Если нельзя, SaaS отпадает.

2. Кто основные пользователи?
   Если только разработчики, git‑схема подойдёт. Если продажи, маркетинг и поддержка, понадобится GUI.

3. Сколько скиллов будет через год?
   При сотнях и больше без каталога не обойтись.

4. Кто будет поддерживать решение?
   Self‑hosted реестр — это ещё один сервис с бэкапами, обновлениями и мониторингом.

Рынок не стоит на месте

Тема быстро становится мейнстримом, и к независимым проектам подключаются крупные вендоры. JFrog выпустил Agent Skills Registry как часть JFrog AI Catalog: скиллы в нём сканируются, подписываются и одобряются, а политики использования задаются централизованно с аудитом. В Google Cloud появился Skill Registry — приватный репозиторий для управления скиллами агентов, где каждый скилл упакован вместе с инструкциями, кодом и документацией. Если ваша компания уже живёт в одной из этих экосистем, эти решения тоже стоит рассмотреть.

Итоги

Централизованное хранилище скиллов — не модная надстройка, а естественный шаг для компании, которая использует AI‑агентов шире, чем «пара разработчиков попробовала». Это та же эволюция, которую прошли библиотеки кода: от копирования файлов к менеджерам пакетов и приватным реестрам.

Для старта хватит git‑репозитория и npx skills: это бесплатно, быстро и без привязки к вендору. Когда скиллов станет больше сотни, к ним потянутся нетехнические сотрудники, а ИБ начнёт задавать вопросы, пора переходить на специализированный реестр. Дальше выбор между self‑hosted и SaaS определяется требованиями к данным и наличием людей, готовых поддерживать инфраструктуру.

Ссылки

• Спецификация Agent Skills: https://agentskills.io

• skills (Vercel): https://github.com/vercel‑labs/skills

• RoleCraft: https://github.com/rolecraft‑sh/rolecraft

• Skilly: https://github.com/scalefocus/skilly

• SkillReg: https://skillreg.dev/docs

Все материалы исследования, включая пошаговые гайды по созданию хранилищ на каждой из рассмотренных технологий, собраны в репозитории: https://github.com/alex‑lib/skills‑registries

А как устроено хранение скиллов у вас? Живут в git, в Notion или уже в реестре? Поделитесь опытом в комментариях.