Потому что копирование markdown в каталог — это не установка пакета. Это найм: ассистент получает новый кусок поведения, который завтра столкнётся с уже стоящими скиллами. Скилл здесь — пакет инструкций для AI-ассистента (Claude Code / Cursor): frontmatter, правила, заявленные read/write/calls. Пока входной контур пуст, каждый новый файл в .claude/skills/ — скрытый найм без собеседования и без записи в личное дело.
Я делаю онбординг скиллам. — Гриша, ты совсем что ли? Какой ещё онбординг? Просто скопируй скилл в каталог проекта и всё!
Не всё.
Когда скиллов три — изящно. Когда тридцать — начинается странное. Ассистент сегодня пишет в одном стиле, завтра в другом. Команда срабатывает, но не так. Файл с контекстом куда-то пропадает. Стека нет, эксепшена нет, строчки лога тоже нет. Просто поведение стало другим — и непонятно, с какого коммита.
Скиллы не конфликтуют на уровне типов. Они конфликтуют в поведении — через часы или дни после установки. Пока каждый крутится в изоляции, этого не видно: скилл может быть отлично покрыт эвалами и идеально работать один. Именно поэтому «просто скопируй» звучит разумно — и именно поэтому ломается позже.
Что ломается на практике
На практике картина повторяется:
- Два скилла оба заявляют «пишу пост в LinkedIn». Ассистент выбирает один недетерминированно. Публикации выходят в разном стиле.
- Два скилла пишут в один файл общего состояния. Last-write-wins постепенно уничтожает накопленный контекст.
- Новый скилл берёт на себя зону соседнего. Узнаёшь об этом, когда следующий шаг пайплайна перестаёт получать ожидаемые данные.
- Один скилл свободно вызывает ещё четыре. Одна правка расходится по цепочке, ломает детерминизм и тратит впятеро больше токенов.
- Два «финализатора» оба претендуют на последнее слово. Итоговый артефакт скачет между их стилями.
Это не баги конкретных скиллов. Конфликт возникает там, где несколько скиллов работают в одном проекте. Пока вы мержите чужой skill-пак как npm install, вы нанимаете человека без собеседования — и платите за это не в момент merge, а неделю спустя, когда регрессия уже в ежедневной работе команды.
Метрика, ради которой стоит возиться: конфликт пойман до того, как скилл стал частью привычной работы команды.
Что из этого следует на практике
Я собрал скилл, который онбордит другие скиллы — ai-agent-onboarding. Не потому что «так правильно по процессу», а потому что иначе нет места, где заявленное поведение сверяют с наблюдаемым — до того, как новый скилл оказался в одном каталоге с остальными.
Пишешь /onboard fb-post-writer — и onboard читает SKILL.md, прогоняет детекторы, гоняет кандидата в песочнице, собирает findings, показывает их тебе и только после подтверждения пишет карточку в .onboarding-registry/.
Модель взята из HR не ради красивой аналогии. У найма уже есть язык для того, чего у скиллов пока нет:
| Найм | Onboarding скилла |
|---|---|
| Резюме | SKILL.md + frontmatter |
| Интервью | Прогон в песочнице по probe-промптам |
| Security clearance | Уровень L1–L4 |
| Испытательный срок | Первые N вызовов под повышенным вниманием |
| Reporting line | Финализатор домена |
| Exit interview | Запись в архив с причиной удаления |
Ключевой смысл sandbox interview: clearance ставится по наблюдаемому, не по заявленному. Скилл с гордым L2 в описании, который правит shared state без объявления в writes, переклассифицируется в L3 — потому что харнесс всё равно даст ему всё, что разрешено в settings.json. Без этого шага вы верите резюме. С ним — смотрите, что человек реально делает на испытательном.
Параллельно шесть детекторов конфликтов (domain usurpation, tool collision, trigger overlap, output-path collision, spaghetti interactions, authority conflict) отвечают на другой «зачем»: где именно новый скилл пересечётся с уже установленными. Severity всего три уровня — block / warn / info. Больше не калибруется: иначе это уже не шкала, а оценка на глаз.
И ещё один «зачем» в обратную сторону: регистр advisory, не enforcement. Он пишет карточку и рекомендует патчи, но ничего не блокирует в рантайме. Жёсткий quarantine чужого скилла из вендорского пакета стоит дороже проигнорированного warning. Онбординг нужен, чтобы решение было осознанным — не чтобы автоматика запрещала команде работать.
Регистр .onboarding-registry/ лежит в корне проекта, не под .claude/: скиллы ставят из источников, которые команда не контролирует, а карточки о них хранятся и версионируются отдельно от харнесса.
Методика, таблицы, failure modes — в howto: Skill onboarding governance.
Где мотив не сработает
- Advisory не блокирует. Команда может проигнорировать report и получить тот же конфликт. Защиты от безразличия нет — это сознательный выбор в пользу обратимости.
- Детекторы дают false positives на легитимных пересечениях доменов (два writer-скилла под разные платформы).
policies.mdэто закрывает, но руками. - Lazy intake. Скиллы, установленные до появления
onboard, попадают в реестр какlazy_intake: true— данные неполные, sandbox-интервью не было. Без явного re-onboarding они так и остаются с дырявой карточкой. - Sandbox ≠ прод. Скилл, которому нужен живой MCP к приватному сервису, деградирует до «paper interview». Честный fallback, но findings там слабее.
- L4 без ревьюера. Уровень «модифицирует харнесс» эскалирует severity, но если у изменений нет назначенного человека, эскалация превращается в шум.
Если findings из /onboard всё равно никто не читает, реестр станет ещё одной папкой в git — конфликт вылезет тем же путём, только с красивой карточкой рядом.
Для кого это «зачем»
Для CTO, Head of AI, tech lead и архитекторов, которые раздают vibe-coding команде и уже тащат в проект чужие skill-паки — vendor, shared library, personal toolbox. Вопрос не «как красиво оформить registry». Вопрос — зачем новый скилл попадает к ассистенту без проверки, если людей вы уже нанимаете по нормальному процессу.
Соседний слой — правила для кода, который пишет ИИ: Cursor rules как governance. Там — стандарты на вывод модели. Здесь — зачем вообще дисциплинировать введение нового компонента поведения самого ассистента. Обычно нужны оба.
Итог
Скилл попадает в проект так же, как нанимается человек: резюме, интервью, испытательный срок, запись в личное дело. Не дисциплина запрета — дисциплина введения. Онбординг нужен не потому что «так принято в enterprise», а потому что без него у вас нет момента, в котором конфликт ещё можно увидеть — до того, как останется только «поведение стало другим».
Репозиторий: github.com/dobryakov/ai-agent-onboarding
Howto: dobryakov.com/howto/skill-onboarding-governance.html
Рядом по теме: book-as-context как способ дать агенту предметный контекст, и периметр безопасности, когда одного system prompt мало.