Скилл, который онбордит другие скиллы

Проблема

Skills — это markdown-файлы с frontmatter и инструкциями. Когда их в проекте набирается несколько десятков, ассистент начинает плыть: сегодня пишет в одном стиле, завтра в другом; файл с контекстом куда-то пропадает; команда срабатывает, но не так. У вас нет ни стек-трейса, ни эксепшена, ни сообщений об ошибках в логе — поведение поменялось, и непонятно когда и почему. Конфликт проявляется только в работе, через часы или дни после установки — на уровне типов никакого сигнала нет.

Вот что происходит:

Два скилла отвечают за одно и то же — оба пишут посты в LinkedIn, ассистент выбирает недетерминированно, стиль плывёт.
Два пишут в один файл; last-write-wins постепенно стирает контекст.
Новый без объявления берёт кусок соседней зоны. Узнаёшь, когда downstream перестаёт получать ожидаемые данные.
Один скилл без ограничений вызывает ещё четыре — правка в соседнем расходится по цепочке, ломает детерминизм и гонит впятеро больше токенов.
Два «финализатора» перетягивают финал на себя, артефакт мечется между их стилями.

Каждый из них может быть покрыт эвалами и работать идеально в изоляции. Конфликт рождается на стыке с соседями — и до этого стыка его не видно.

Методика

Решение собрано как сам скилл. Пишешь /onboard fb-post-writer — onboard читает SKILL.md нового скилла, прогоняет детекторы, сажает в песочницу, собирает findings и показывает их тебе. Карточка в .onboarding-registry/ появляется только после подтверждения.

Модель взята из HR: новый скилл — это не npm install, это найм. В найме давно сложился свой словарь, и он ложится сюда без натяжек:

Найм	Onboarding скилла
Резюме	`SKILL.md` + frontmatter
Интервью	Прогон в песочнице по probe-промптам
Security clearance	Уровень L1–L4
Испытательный срок	Первые N вызовов под повышенным вниманием
Reporting line	Финализатор домена
Exit interview	Запись в архив с причиной удаления

Восемь шагов, ключевой — пятый:

Parse SKILL.md. Читает frontmatter и тело: trigger, reads, writes, calls, finalizer.
Conflict detection. Шесть параллельных детекторов: domain usurpation, tool collision, trigger overlap, output-path collision, spaghetti interactions, authority conflict.
Pre-clearance. Предварительная классификация L1–L4 по задекларированным правам.
Sandbox setup. Создаёт изолированную директорию, поднимает sub-агент-наблюдатель.
Sandbox interview. Запускает скилл на 2–3 синтетических probe-промпта; наблюдатель фиксирует факты.
Observed vs declared. Наблюдатель сверяет задекларированное с реально наблюдаемым, пересчитывает clearance.
Findings report. Собирает все findings с severity (block / warn / info) и показывает тебе.
Registry card. Только после подтверждения пишет карточку в .onboarding-registry/.

Ключевой — пятый, sandbox interview. Onboard запускает скилл на 2–3 синтетических промпта в изолированной директории под отдельным sub-агентом; наблюдатель сверяет заявленное с наблюдаемым:

Declared	Observed	Finding
`reads: [A, B]`	Читает A, B, C	Undeclared read
`writes: [outputs/X/]`	Пишет в `state/Y`	Эскалация clearance до L3
`calls: [skill-A]`	Вызывает A и B	Undeclared dependency

Onboard ставит итоговый clearance по тому, что скилл реально делает в песочнице. Гордое L2 в описании ничего не значит, если скилл молча правит shared state: его переклассифицируют в L3, потому что харнесс всё равно даст ему всё, что разрешено в settings.json.

Параллельно работают шесть детекторов конфликтов: domain usurpation, tool collision, trigger overlap, output-path collision, spaghetti interactions, authority conflict. Severity всего три уровня (block / warn / info): тоньше команда не калибрует, дальше начинается субъективщина.

Регистр работает в advisory-режиме: пишет карточку, рекомендует патчи к описанию или к settings.json, но рантайм не трогает. Если жёстко блокировать скилл из вендорского пакета, регистр превращается в вахтёра — ошибочный quarantine стоит дороже, чем проигнорированный warning. Эскалация до hard enforcement — отдельный явный шаг, пользователь решает сам.

Реестр (.onboarding-registry/) живёт в корне проекта, не под .claude/. Скиллы попадают в проект из источников, которые пользователь не контролирует; реестр — мнение проекта о них, и оно версионируется отдельно от харнесса.

Артефакт

github.com/dobryakov/ai-agent-onboarding — onboard skill, схема реестра, шесть детекторов, рубрика L1–L4. Только что выложен, traction пока нет; смотреть стоит на саму механику.

Подпись серии

Где ломается

Advisory не блокирует. Команда может проигнорировать report и получить тот же конфликт. Никто её не остановит: автоматический запрет стоит дороже, чем пропущенный warning.
Детекторы дают false positives на легитимных пересечениях доменов (например, два writer-скилла под разные платформы). Снимается через policies.md, но руками.
Lazy intake — компромисс. Скиллы, установленные до появления onboard, попадают в реестр как lazy_intake: true — данные неполные, sandbox-интервью не было. Без явного re-onboarding они так и остаются полу-вслепую.
Sandbox ≠ прод. Скилл, требующий живого MCP к приватному сервису, деградирует до «paper interview» — предсказание поведения по чтению. Приемлемый fallback, но качество findings в этом случае ниже.
L4 — формальность без ревьюера. Уровень «модифицирует харнесс» поднимает severity, но без ответственного ревьюера поднимать её бессмысленно — все алерты уходят в фон.

Для кого и почему

Риск: команда разворачивает агент-стек, скидывает в проект чужие skill-паки (vendor, shared library, personal toolbox) — и через пару месяцев тратит часы на разбор недетерминированного поведения, которое нельзя воспроизвести юнит-тестом.

Onboard встраивает скилл в проект так же, как нанимают человека: резюме, интервью, испытательный срок, запись в личное дело. Не дисциплина запрета, а дисциплина введения.

Главная проверка — конфликт найден до мерджа скилла в daily flow, а не неделю спустя, когда регрессия уже дотянулась до downstream.

Прямая связь с #7 Cursor rules как governance: там правила для кода, который пишет ИИ; здесь — правила для самого ассистента, когда в проект вводится новый компонент его поведения. Для CTO, который разворачивает вайб-кодинг в команде, это следующий слой того же решения.

Хотите выстроить governance для растущего агент-стека?

Скилл-стек растёт быстрее, чем дисциплина его введения, и поведение агента становится непредсказуемым. Помогаю выстроить процессы, которые держат контроль по мере роста экосистемы.

Написать на почту

Другие разборы

Серия инженерных разборов: реальная задача → методика → работающий артефакт → честный разбор, где он ломается.

К серии →