Централизованные хранилища скиллов для 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‑реестр делает для кода. Никто не пишет свою версию одной и той же функции с нуля: есть единый источник правды, откуда все берут и куда все публикуют обновления.

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

Задача	Как решается
Единый источник правды	Один каталог на всю компанию вместо разрозненных копий
Версионирование	Можно опубликовать v2, не сломав тех, кто ещё работает на v1
Контроль качества (governance)	Скилл проходит review/approval, прежде чем попасть ко всем сотрудникам
Безопасность	Автоматическое сканирование на вредоносный код и секреты перед публикацией
Аудит	Фиксируется, кто опубликовал, кто одобрил и кто установил скилл
Отзыв (revocation)	Проблемную версию можно централизованно заблокировать, не рассчитывая, что все удалят файл вручную
Единообразная установка	Одна команда вместо ручного копирования файлов
Изоляция по командам	Скиллы продаж и разработки не смешиваются, но доступны из одного места

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

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

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

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

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

Термин	Простыми словами
Git / GitLab / GitHub	Система хранения файлов с историей изменений и платформы на её основе
CLI	Программа, которой управляют командами в терминале
Registry (реестр)	Специализированный каталог «пакетов» с версиями, поиском и правами доступа
Installer	Программа, которая скачивает скилл и раскладывает его по папкам агентов
Semver	Нумерация версий `MAJOR.MINOR.PATCH`: `2.0.0` означает несовместимые изменения, `1.3.0` — новые возможности, `1.2.1` — исправления
Immutable‑версия	Опубликованную версию нельзя изменить задним числом, только выпустить новую
Yank / revoke	Пометить версию как непригодную для новых установок / полностью отозвать её
RBAC	Управление доступом по ролям: кто смотрит, кто публикует, кто одобряет
SSO / OIDC	Вход под корпоративной учётной записью без отдельного пароля
SCIM	Автоматическая синхронизация пользователей: уволенный сотрудник сам теряет доступ
Self‑hosted / SaaS	Решение разворачивается на своих серверах / работает в облаке поставщика
Lock‑файл	Файл, где зафиксировано, что именно и в какой версии установлено
Symlink	«Ярлык» на папку: несколько агентов смотрят на одну копию скилла

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

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

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

Хранилище (registry) — место, где живут корпоративный каталог, версии, права доступа и история. Это может быть GitLab/GitHub или отдельный реестр.
Installer (package manager) — клиент, который берёт скилл из хранилища и физически кладёт его в директории агентов: Claude Code, Cursor, Codex, Copilot и других.

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

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

Вариант	Центральное хранилище	Как ставится скилл	Поиск / каталог	Обновления
GitLab/GitHub + `npx skills`	Репозиторий или группа в GitLab/GitHub	`npx skills add <git-url>`	UI GitLab/GitHub + README; отдельного каталога нет	`npx skills update`
GitLab/GitHub + RoleCraft	Репозиторий или группа в GitLab/GitHub	`rolecraft install <source>`	GitLab/GitHub + поиск в CLI	`rolecraft check`, `update`, `rollback`
Skilly	Self‑hosted реестр внутри компании	Сгенерированная команда `npx skills add <url>`	Веб‑каталог, неймспейсы, RBAC	Immutable semver; доставка через `npx skills`
SkillReg	Облачный приватный реестр (SaaS)	`skillreg pull @org/skill` или Desktop App	Встроенный полнотекстовый каталог	Повторный `pull` latest или semver‑диапазон

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

Вариант 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 использует цепочку запасных вариантов:

создать symlink;
если не получилось — directory junction (аналог ссылки, не требующий повышенных прав);
если и это не сработало — скопировать файлы. Связь с каноничной копией при этом теряется.

Режим копирования можно включить и явно — флагом --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 позволяют выбрать один скилл даже из огромного репозитория. Но упираемся в два ограничения:

Доставка. CLI использует shallow clone, а поддержка sparse‑checkout для больших монорепозиториев на момент исследования была открытым вопросом в трекере проекта. Поэтому выбор одного скилла не гарантирует, что по сети скачается только его папка.
Поиск. Дерево файлов и поиск по коду в 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, есть нативное десктопное приложение, которое позволяет просматривать и устанавливать скиллы без терминала.

Внедрение

Регистрация организации в веб‑интерфейсе.
Настройка ролей: кто публикует (push), кто только устанавливает (pull), кто одобряет.
Установка CLI авторами скиллов:
```
npm install -g @skillreg/cliskillreg login
```
Импорт существующих скиллов — из GitHub или вручную через skillreg init + skillreg push.
Раскатка на пользователей: CLI или десктопное приложение.
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. Если нужна стабильность, закрепляйте версию или диапазон явно.

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

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

Критерий	Git + `npx skills`	Git + RoleCraft	Skilly	SkillReg
Приватное централизованное хранение	Да (за счёт git)	Да (за счёт git)	Да	Да
Отдельный реестр скиллов	Нет	Нет	Да	Да
Размещение	Self‑hosted	Self‑hosted	Self‑hosted	SaaS
macOS / Windows / Linux	Да	Да	Да	Да
Несколько источников за вызов	Отдельные команды	`bundle`	Через каталог	`pull-all` по организации
Автоопределение агентов	Да	Да	Да (через `npx skills`)	Нет, явный `--agent`
Versioning	Git refs/tags	Git refs + lock/история	Immutable semver	Immutable semver
Откат версии	Через git	`rollback`	Закрепление версии	Закрепление версии
Встроенный каталог с поиском	Нет	Частично (CLI)	Да	Да
Approval/RBAC на уровне скилла	Уровень репозитория	Уровень репозитория	Да	Да
Security‑скан	Через CI	Локальный + CI	Да	Да
Аналитика установок	Нет	Нет	Да	Да
UX при 1000+ скиллов	Средний/плохой	Средний	Хороший	Хороший
GUI для нетехнических сотрудников	Нет	Нет	Веб‑каталог	Десктоп‑приложение

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

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

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

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

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

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

Как выбрать

Ваша ситуация	Что подойдёт
Техническая команда, десятки скиллов, нужен быстрый старт	GitLab/GitHub + `npx skills`
То же, но скиллы из разных репозиториев, нужны откат и оценка риска	GitLab/GitHub + RoleCraft
Сотни скиллов, строгие требования ИБ, данные не должны покидать периметр, есть DevOps‑ресурс	Skilly
Скиллами пользуются нетехнические сотрудники, нет ресурса на инфраструктуру, облако допустимо	SkillReg

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

Можно ли хранить скиллы вне периметра?
Скиллы часто содержат внутренние процессы и знания компании. Если нельзя, SaaS отпадает.
Кто основные пользователи?
Если только разработчики, git‑схема подойдёт. Если продажи, маркетинг и поддержка, понадобится GUI.
Сколько скиллов будет через год?
При сотнях и больше без каталога не обойтись.
Кто будет поддерживать решение?
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 или уже в реестре? Поделитесь опытом в комментариях.

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