BTO: измерить навык, а не поверить ему

Тимур написал для команды навык code-review, и всем он понравился: текст читался гладко, коллеги кивали. Через неделю выяснилось, что агент по этому навыку выдаёт на одном и том же коде то три замечания, то ни одного.

Дело не в модели. Дело в том, что навык никто не измерял — его только читали. Вот эту дыру и закрывает BTO: это конвейер из четырёх модулей.

1. BUILD — сгенерировать артефакт из описания на человеческом языке.
2. BENCHMARK — измерить его детерминированно, почти без вызовов модели.
3. TEST — оценить панелью судей-моделей.
4. OPTIMIZE — улучшить эволюционно и доказать улучшение числом.

«Артефакт» здесь — любой файл, по которому работает агент: навык (SKILL.md), команда, правило, шаблон агента.

Порядок модулей не случайный: сначала дешёвое, потом дорогое. Если BENCHMARK уже сказал «структура сломана», нет смысла оплачивать работу трёх судей — они найдут ту же поломку, только за деньги.

Компромисс: ты платишь дисциплиной — прогнать конвейер дольше, чем просто перечитать файл глазами. Взамен получаешь число, которое можно сравнить до и после правки, и вердикт, который не зависит от твоего настроения.

Пакет открытый: @dzhechkov/skills-bto на npm, исходники — на GitHub.

Первое, что сделал Тимур, — запустил установку в рабочем проекте, где уже лежали свои файлы в .claude/. Ничего страшного не произошло, но он до последнего не знал, что именно перезапишется.

Есть три способа поставить пакет:

• npx @dzhechkov/skills-bto — разовая установка без глобального пакета;
• npm install -g @dzhechkov/skills-bto и затем skills-bto init — если ставишь часто;
• npx @dzhechkov/skills-bto init — установка в проект, где уже есть Keysarium.

Главная привычка курса: сначала предпросмотр, потом установка. Флаг --dry-run показывает список файлов, которые появятся или будут перезаписаны, и не меняет на диске ничего:

npx @dzhechkov/skills-bto init --dry-run   # показать план
npx @dzhechkov/skills-bto init             # выполнить
npx @dzhechkov/skills-bto init --force     # перезаписать существующее

После установки полезны ещё три команды: list покажет установленные компоненты, doctor проверит здоровье установки, remove аккуратно снимет пакет.

Компромисс: --dry-run — лишний шаг, и в чистом проекте он выглядит формальностью. Но именно в грязном проекте, где уже есть свои .claude/commands/, этот шаг и стоит своих десяти секунд.

Требования простые: Node.js не ниже 16 и установленный Claude Code. Ссылки под рукой: пакет на npm и репозиторий на GitHub.

Тимур ожидал увидеть один файл. Увидел семь видов компонентов — и сначала растерялся.

Разложим по полкам. Навык — один, называется bto, это оркестратор из четырёх модулей. Команд — пять: /bto, /bto-build, /bto-benchmark, /bto-test, /bto-optimize; команда — это точка входа, короткий файл, который говорит агенту, какой навык и какой модуль прочитать. Правило — одно, bto-quality-gates: правило читается всегда и держит пороги гейтов. Шард — один, bto-evaluation; шард (shard) здесь — кусок контекста, который подгружается под конкретную задачу, чтобы не тащить весь навык целиком.

Дальше — материал для агентов. Шаблонов агентов два: bto-judge-panel (панель судей) и bto-optimizer-worker (рабочий оптимизации). Референсов пять: паттерны оценки, рубрики судей, методы оптимизации, чек-лист качества и золотые образцы. Примеров два — готовые отчёты, на которые можно смотреть как на образец формата.

Важное свойство: всё это ложится в .claude/ твоего проекта обычными markdown-файлами. Ничего не прячется в бинарниках, любой компонент можно открыть и прочитать — и это же означает, что любой можно случайно испортить руками.

Компромисс: прозрачность против хрупкости. Ты видишь каждый файл и можешь его поправить под себя, но обновление пакета (update) увидит твои правки как расхождение.

Тимур поступил как большинство: на каждый чих запускал /bto — полный цикл. Это работает, но платить полную цену там, где нужна одна проверка, обидно.

Пять команд, по одной задаче на каждую:

• /bto <путь или описание> — полный цикл. Если аргумент — существующий путь, BUILD пропускается, и цикл начинается с BENCHMARK.
• /bto-build <описание> — сгенерировать новый навык или команду из описания словами.
• /bto-benchmark <путь> — только детерминированное измерение: золотые образцы, тестовый набор, проба на устойчивость, метрики.
• /bto-test <путь> — только оценка: слой 0 и панель судей.
• /bto-optimize <путь> — только улучшение существующего артефакта.

Правило выбора простое: бери самую узкую команду, которая отвечает на твой вопрос. «Файл вообще пригоден?» — /bto-benchmark. «Насколько он хорош по существу?» — /bto-test. «Как сделать лучше?» — /bto-optimize.

Есть и приятная деталь: команды не надо заучивать. В Claude Code ты пишешь словами — «прогони бенчмарк по моему навыку code-review» — и ассистент сам подставит нужную команду с нужным путём. Команды в курсе нужны, чтобы ты понимал, что происходит под капотом.

Компромисс: узкая команда дешевле и быстрее, но она не увидит проблему за пределами своего модуля. Полный /bto дороже, зато ловит и структурную поломку, и содержательную слабость за один заход.

Когда Тимур увидел «BENCHMARK: 0.62», первый вопрос был правильный: из чего это число сложилось?

Оно складывается из четырёх слоёв, и у каждого свой вес:

1. B0 — сравнение с золотыми образцами (вес 0.30). Золотой образец — структура заведомо хорошего артефакта того же типа. Слой считает три вещи: покрытие разделов, порядок разделов и пропорции — не раздулся ли один раздел до половины файла.
2. B1 — детерминированный набор тестов (вес 0.35, самый тяжёлый). Здесь проверяют то, что решается правилом: разрешаются ли внутренние ссылки, одним ли термином называется одно понятие, нет ли расплывчатых указаний вроде «сделай хорошо», есть ли раздел анти-паттернов хотя бы с тремя записями.
3. B2 — проба на устойчивость (вес 0.15). Три дешёвых агента получают один и тот же вход и отвечают независимо. Расхождение ответов означает не глупость агентов, а двусмысленность инструкции.
4. B3 — метрики (вес 0.20). Плотность смысла на токен, баланс разделов, доля утверждений, подкреплённых ссылками.

Итоговая формула записывается так:

BENCHMARK = B0×0.30 + B1×0.35 + B2×0.15 + B3×0.20

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

Компромисс: три слоя из четырёх бесплатны и мгновенны, но они меряют структуру, а не смысл. Высокий BENCHMARK означает «файл сделан по правилам», а не «навык полезен» — за смысл отвечает следующий модуль.

А теперь неожиданное. Перед всеми измерениями работает слой B-1 — он ничего не оценивает. Он проверяет, может ли каждый следующий слой вообще выполниться, и записывает ответ.

Проверок ровно четыре: читается ли путь к артефакту и его каталог; есть ли в файле золотых образцов запись для этого типа артефакта; отвечает ли инструмент агентов на пробный запрос; доступны ли внешние утилиты, которые дёргает B1.

Результат печатается одной строкой в шапке отчёта:

Preconditions: ALL_GREEN | DEGRADED(B2: инструмент агентов недоступен) | ABORT(путь нечитаем)

Вот тут и живёт сюрприз, ради которого Тимур это запомнил: строка печатается всегда, даже когда всё зелёное. Логика такая: если печатать её только при поломке, слой становится необязательным, а необязательная проверка честности — ровно та поломка, от которой этот слой и защищает. Поэтому правило звучит наизнанку: отсутствие строки само по себе является находкой.

У состояния DEGRADED есть выход, а не оправдание. Если не хватает утилиты, её можно поднять локально: распаковать во временный каталог, запустить на свободном порту, снести после прогона. Чего делать нельзя — трогать чужие живые сервисы: измерение, которое меняет измеряемое окружение, перестаёт быть измерением.

Компромисс: лишняя строка в каждом отчёте — цена того, что «у меня всё прошло» больше нельзя сказать про прогон, который просто не состоялся.

Вопрос, на который нет удобного ответа: что делать со слоем, который просили выполнить, а он не смог?

Тимур ответил первое, что приходит в голову: «ну и ладно, посчитаем по остальным». Именно это и запрещено. Если убрать слой из знаменателя и перераспределить его вес, счёт может только вырасти: пробел в доказательствах превращается в оценку получше. Поэтому в конвейере есть третий вердикт — INCONCLUSIVE: не пройдено и не провалено.

Строк вердикта пять, и они разбираются сверху вниз, первая подошедшая выигрывает:

1. B-1 вернул ABORT → ABORT, счёт не выпускается вовсе.
2. Хоть один слой INCONCLUSIVE → INCONCLUSIVE, к TEST не переходим.
3. Счёт меньше 0.50 → BLOCK, артефакт нужно чинить.
4. Счёт 0.50–0.70 → WARN, идём дальше, но судьи получают предупреждение.
5. Счёт выше 0.70 → PASS.

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

И ещё два следствия. Первое: знаменатель — это выполненные проверки, никогда не заявленные. Второе: INCONCLUSIVE липнет вниз по конвейеру — если бенчмарк неопределён, TEST не начинается; если неопределён слой внутри TEST, весь отчёт неопределён.

Есть законное исключение: слой, который ты сам сознательно отключил флагом --level, из знаменателя убирается. Разница принципиальная — отключено намеренно и запрошено, но не смогло это разные вещи.

Компромисс: вердиктов становится больше, и часть прогонов заканчивается без оценки вообще. Зато ни один прогон не выдаёт число, которое он не заслужил.

Тимур сначала попросил одну модель: «оцени мой навык». Получил 8 из 10 и обрадовался. Проблема в том, что один судья оценивает ровно то, что умеет замечать.

Поэтому в модуле TEST работает панель из трёх независимых судей, у каждого своя роль:

• Эксперт предметной области (вес 0.4) — точность, глубина, соответствие домену.
• Критик (вес 0.3) — пробелы, слабые места, анти-паттерны, крайние случаи.
• Аудитор полноты (вес 0.3) — структура, покрытие, разрешаются ли перекрёстные ссылки, применим ли артефакт на практике.

Слово «независимых» здесь несёт нагрузку: судьи не видят оценок друг друга до того, как выставят свою. Иначе первая озвученная оценка становится якорем, и панель вырождается в одного судью с двумя подпевалами.

Каждый оценивает по пяти измерениям от 1 до 10: методология, глубина, корректность, применимость, устойчивость к нештатным случаям.

Если по какому-то измерению разброс между судьями больше 3 баллов, включается мета-судья: более дорогая модель получает все три оценки и выносит примирённую с явным обоснованием. Разброс — это не шум, а сигнал, что артефакт по-разному читается.

Панель — верхний, самый дорогой этаж лестницы: слой 0 (детерминированные проверки) → слой 1 (один дешёвый судья) → слой 2 (панель). Наверх не поднимаются, пока нижний гейт не пройден.

Компромисс: три судьи стоят втрое дороже одного и работают дольше. Взамен ты получаешь разброс оценок — а он часто информативнее самой оценки.

Тимур нашёл отчёт полугодовой давности с оценкой 8.6 и не смог ответить на простой вопрос: кто это писал и кто это судил? Из-за этого числу нельзя было верить — не потому, что оно плохое, а потому, что неизвестно, чьё оно.

Поэтому каждый отчёт оценки всегда печатает три строки провенанса — то есть происхождения:

Authored by:  claude-opus (anthropic)
Judged by:    Expert=claude-sonnet | Critic=gpt-5.5 | Auditor=claude-sonnet
Cross-family: YES (Critic=openai — другое семейство, чем автор)

«Семейство» — это поставщик модели. Здесь работают два разных правила, и их легко перепутать.

Правило про семейство — рекомендательное. Хорошо, когда место Критика занимает модель другого семейства: она замечает не то, что автор. Но если второе семейство недоступно, отчёт не блокируется — он печатает громкий баннер SAME-FAMILY PANEL и честно говорит, что корректность и устойчивость здесь оценены самопроверкой.

Правило про тождество модели — блокирующее. Одна и та же модель не может и написать артефакт, и судить его. Это не совет, а запрет: самопроверка выдаёт слишком хорошие оценки, потому что судья повторяет собственные предпосылки.

Запомни разницу так: семейство — записывается, тождество — запрещается.

Компромисс: три лишние строки в каждом отчёте и иногда громкий баннер вместо тихого зелёного. Но отчёт, прочитанный через полгода, отвечает сам за себя, без археологии по чатам.

Посмотри сначала на схему внизу секции — она объясняет модуль быстрее, чем абзац: круг из трёх раундов, где выход каждого становится входом следующего.

Модуль OPTIMIZE устроен эволюционно. Раунд 1: пять параллельных дешёвых агентов порождают пять вариантов артефакта и быстро их ранжируют. Раунд 2: лучшие варианты идут на оценку панелью посерьёзнее. Раунд 3: финалисты проходят полную оценку панелью судей. Каждый раунд берёт лучший вариант и делает его основой следующего.

Мутации не случайные, у них есть имена, и каждое лечит своё:

1. Перефразировать — когда просела ясность.
2. Переструктурировать — когда просела применимость.
3. Добавить ограничения — когда артефакт разваливается на крайних случаях.
4. Упростить — когда он переусложнён.
5. Специализировать — когда не хватает глубины по домену.

Три правила приёмки, которые Тимур выписал себе отдельно:

• вариант принимается, только если прирост оценки больше 0.5;
• падение больше 1.0 — автоматический откат к предыдущему лучшему;
• три раунда подряд с приростом не больше 0.5 — объявляется сходимость, оптимизация останавливается.

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

Компромисс: оптимизация легко переучивается под метрику — вариант получает высокий балл у судей, но становится хуже для живого пользователя. Поэтому есть жёсткий предел раундов и правило «не оптимизируй артефакт, у которого базовая оценка уже выше 8».

Самая дорогая мелочь во всём курсе. SKILL.md обязан начинаться с забора (fence) — блока из трёх дефисов с полями name: и description: — до заголовка # Название:

---
name: bto
description: Build, benchmark, test, and optimize Claude Code artifacts.
---

# BTO — Build · Test · Optimize
```

Почему это дорого: загрузчик обходит каталог целиком, и один файл без забора заставляет харнес отвергнуть весь каталог навыков, а не только виноватый файл. Один сломанный навык прячет все остальные.

Теперь главное — как это ловится. Тимур сначала проверил раскладку и успокоился:

dz skills-verify --dir templates --static --json   # exit 0, {"registrable":["bto"]}
dz list --skills-dir templates/.claude/skills      # exit 1, 'SKILL.md must begin with a "---" frontmatter fence'

Оба прогона были сделаны на одном и том же неисправленном дереве 18 августа 2026 года — и они разошлись. Статическая проверка раскладки никогда не заходит в код разбора забора, поэтому она зелёная на дереве, где загрузка сломана. Различает только вторая команда.

Отсюда понятие, которое стоит унести из курса целиком: различающий оракул — это проверка, которая даёт разный ответ на исправном и неисправном дереве. Проверка, зелёная в обоих случаях, не доказывает ничего, сколько бы галочек она ни ставила.

И ещё деталь, записанная как решение, а не как забывчивость: команды, правила и шаблоны агентов забора не получают — разборщик, который его требует, читает только навыки.

Компромисс: забор — лишние четыре строки в каждом навыке и одна из самых частых причин «у меня ничего не грузится». Зато сбой громкий и воспроизводимый одной командой.

Тимур поручил агенту собрать отчёт оценки. Агент думал долго, ничего не записывал — и был убит сторожевым таймером. Результат: ноль строк на диске. Не половина отчёта, не черновик — ноль.

Правило, которое из этого следует, обязательно для каждого агента конвейера BTO:

1. Сначала одной маленькой записью создай файл: заголовок и скелет разделов.
2. Дальше дописывай по частям — по одной правке на раздел или примерно на сотню строк, что короче.
3. Шесть маленьких вызовов лучше одного большого, даже когда большой «наверное, поместится».

Цифры, ради которых это не спор о вкусах: агент, не подавший ни одного признака жизни, убивается через 180 секунд внутри исполнителя конвейера и через 600 секунд, если он запущен как отдельный подагент. Частичного сохранения нет — убитый агент теряет всё ненаписанное.

Важно: это не свойство «слабых» моделей. Сторож убивает любую модель одинаково.

Есть законные исключения — ответ пробы на устойчивость или однострочная оценка варианта. Но исключение обязано быть записано на месте токеном INCREMENTAL-WRITE: EXEMPT (short output). Смысл требования простой и стоит того, чтобы его запомнить: умолчание и осознанное исключение должны различаться поиском по тексту. Иначе через полгода никто не отличит «здесь так решили» от «здесь забыли».

Компромисс: записей больше, файл какое-то время лежит недописанным, и промежуточное состояние может увидеть посторонний. Зато лишняя запись стоит миллисекунды, а убийство агента — всего прогона.

Последний вопрос курса — и он про тебя, а не про пакет: чему из своего вчерашнего отчёта ты сможешь верить через полгода?

Тимур уже знает два ответа: строка Preconditions скажет, что реально выполнялось, а строки провенанса — кто писал и кто судил. Третий ответ — цепочка свидетельств (witness chain).

Механика простая. Для каждого артефакта считается хеш SHA-256 не от одного его содержимого, а от содержимого вместе с хешем предыдущего звена:

CHAINED_HASH=$(printf '%s%s' "${FILE_CONTENT}" "${PREV_HASH}" | sha256sum | awk '{print $1}')

Первое звено берёт вместо предыдущего хеша NULL_HASH — 64 нуля. Дальше каждая правка любого артефакта ломает не только его собственный хеш, но и все последующие. Это и называется устойчивостью к подмене: не «изменить нельзя», а «изменение нельзя скрыть».

Две детали, на которых чаще всего спотыкаются. Первая: printf '%s%s', а не echo — иначе лишний перевод строки даст другой хеш. Вторая: содержимое хешируется как лежит на диске — без обрезки пробелов, без нормализации переводов строк, без снятия BOM. Любая «уборка» перед хешированием ломает проверяемость.

У судей есть свой вариант того же приёма — аттестация. Каждый судья фиксирует хеш от связки «идентификатор судьи, хеш артефакта, оценка, краткое обоснование» до того, как увидит чужие оценки. Хеш артефакта у всех троих одинаковый — это доказывает, что судили один и тот же файл; порядок фиксации доказывает, что независимость не была нарушена задним числом.

Компромисс: цепочка ничего не говорит о качестве работы — она доказывает только целостность и порядок. Зато это единственное свойство отчёта, которое не зависит ни от чьей добросовестности.