Скил self-verification — трёхслойная проверка артефактов

Когда та же модель, которая создала артефакт, проверяет его сама — итогом обычно становится подтверждение, а не критика. Скил self-verification построен на этом наблюдении. Верификация выполняется в три слоя, каждый использует разный источник сигнала, и артефакт считается чистым только тогда, когда все три не возвращают выводов высокой критичности.

Скил вызывается вручную через /dr-verify {TASK-ID}. Он не является автоматическим хуком пайплайна — этот путь является отложенной будущей эволюцией с порогом dogfood. Подходящий объект проверки — завершённый артефакт: PRD, план, do-output или архив. Запуск во время активной сессии — неправильный момент.

Слой 1 — детерминированный базис

Первый слой — shell-конвейер с нулевой стоимостью LLM. Выполняется за 2–5 секунд на типичной задаче. Проверки эвристические, но конкретные: каждый идентификатор критерия приёмки в PRD должен иметь рядом команду верификации; каждый путь к файлу, упомянутый в плане, должен разрешаться в рабочем пространстве; shellcheck запускается против всех shell-скриптов в стандартных директориях; для задач L3 и L4 чеклист ожиданий должен присутствовать и не должен находиться в состоянии BLOCKED.

Базис завершается с количеством выводов высокой критичности. Ненулевой результат трактуется как BLOCKED; оркестратор может пропустить слои 2 и 3 для быстрого отказа, хотя операторам, которым нужна только детерминированная проверка, достаточно явно передать --floor-only.

Слой 2 — кросс-модельный peer-review

Второй слой отправляет артефакт внешней модели через CLI coworker. Провайдер разрешается через шестишаговую цепочку: сначала явный CLI-флаг, затем конфигурация проекта, затем пользовательская конфигурация, затем дефолтный профиль coworker, затем кросс-Claude-family субагент, и в последнюю очередь — изолированный fallback на той же модели. На четвёртом шаге цепочки выбирается провайдер, объявленный как рекомендуемый в конфигурации профиля --profile code инструмента coworker — жёстко прописанного значения нет. Свойство, важное для снижения bias, — использование другого вендора с другим тренировочным прогоном, нежели у модели, создавшей артефакт.

Состязательное оформление, отправляемое ревьюеру, обязательно и специфично. Ревьюеру сообщается, что его задача — находить слабые места, а не одобрять документ. Он обязан найти не менее двух существенных замечаний и проверить команды верификации критериев приёмки, паттерны «залогировано, но не запущено», покрытие рефлексии, spawn'ы follow-up задач, воспроизводимость и дрейф за пределы скоупа. Без этого оформления собственные dogfood-эксперименты скила показали, что внешняя модель возвращала 29 completion-токенов и пустой список выводов — тихий ложный pass.

Слой 3 — параллельный dispatch

Третий слой запускает три параллельных субагента в среде выполнения Claude Code: ревьюер сосредоточен на корректности и полноте, тестировщик — на покрытии доказательств и воспроизводимости, агент безопасности — на категории safety и контролях Приложения A. Каждый субагент работает только на чтение — без инструментов Write или Edit. Выводы всех трёх объединяются и дедублируются по кортежу из ссылки на артефакт, критерия приёмки и категории. При совпадении двух выводов побеждает тот, что пришёл из более раннего слоя.

На Codex CLI слой 3 деградирует до single-prompt loop. Этот путь показал лишь 7,7% литерального gap-recall на внутреннем dogfood-базисе из 13 задач — именно поэтому он помечен как экспериментальный. Рекомендуемый путь на Codex — передать --peer-provider deepseek и полагаться на слой 2 для содержательного покрытия.

Схема выводов и вердикт

Каждый вывод содержит тег источника слоя, ссылку на артефакт с номером строки, массив затронутых критериев приёмки, уровень критичности и категорию. Поле категории различает корректность (фактическое утверждение без подтверждающих доказательств), полноту (отсутствующая обязательная часть артефакта), согласованность (дрейф между артефактами) и безопасность (пробел в security или rollback). Выводы с evidence.type=absent автоматически отбрасываются и не учитываются в вердикте.

Вердикт следует простому правилу: любой не отброшенный вывод высокой критичности блокирует артефакт; выводы средней критичности дают условный вердикт, требующий ручной сортировки оператором; только выводы низкой критичности дают pass. Журнал аудита записывается с chmod a-w, что делает его только-для-добавления.

Читайте что такое Datarim для общего контекста или изучите скил security, чтобы понять, как формируются выводы категории safety.