Как научить Claude Code проверять себя: циклы верификации

Если ты уже поработал с Claude Code хотя бы неделю, то наверняка заметил один паттерн: ты просишь изменение, Claude собирает контекст, что-то делает — а потом ты САМ идёшь и проверяешь результат. Запускаешь приложение, кликаешь по кнопке, смотришь логи, находишь мелкую ошибку, объясняешь её Claude, он чинит. И этот цикл повторяется из раза в раз, причём часто — одними и теми же шагами.

Anthropic называет это «агентным циклом»: сбор контекста → действие → проверка результата → (если нужно) снова сбор контекста. Проверка — это именно тот момент, когда агент должен сам убедиться, что сделал правильно, прежде чем отвечать тебе «готово». И хорошая новость в том, что львиную долю этой рутины можно закодировать один раз и больше не повторять руками.

Что Claude уже умеет проверять сам

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

Именно эти «слепые зоны» — то, что ты каждый раз проверяешь руками — и являются кандидатами на превращение в цикл верификации. В Claude Code это итеративный процесс, где Claude сам находит нарушение и сам же его исправляет, а ты в этот момент можешь заниматься чем-то другим.

Встроенные инструменты, о которых стоит знать

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

Если у тебя настроен Code Review, ты можешь либо вручную исправить найденное и запушить фикс, либо замкнуть цикл прямо в комментарии — написав @claude под находкой (при условии, что GitHub Actions уже настроены). Это уже неплохо закрывает базовые сценарии, но настоящая сила — в том, чтобы закодировать именно ТВОИ повторяющиеся проверки, специфичные для твоего проекта.

Как писать собственные циклы верификации

Если ты замечаешь, что вносишь одну и ту же мелкую правку после каждой новой фичи — самое время записать эту процедуру. Начни с простого: напиши все шаги, которые ты обычно делаешь, простым языком — так, как объяснил бы их новому коллеге в первый день работы. Если проект новый и правил поведения пока нет, всё то же самое: попроси у Claude best practices и отредактируй под свою специфику — как правило, различия будут в паре конкретных пунктов, и именно их стоит зафиксировать.

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

Превращаем проверку в skill

Самый удобный способ закодировать повторяющиеся шаги — оформить их как skill. Быстрее всего это сделать через плагин skill-creator: он буквально интервьюирует тебя о процессе и сам собирает файл. Например: /skill-creator Create a skill for verifying frontend changes end-to-end. Interview me about my workflow.

Можно и написать skill руками — это просто markdown-файл в .claude/skills/. Минимальная версия занимает буквально несколько строк:

## .claude/skills/verify-log-hygiene/SKILL.md
---
name: verify-log-hygiene
description: Check that error logs include the request ID and never
include the request body. Use when the diff touches error handling
or logging.
allowed-tools: [Read, Edit, Grep]
---
Read the error-handling paths in the current diff.

For each log call on an error path, confirm it includes the request ID
and does not pass the request body, headers, or any user-supplied payload.

Report each violation with file:line, then fix it: add the request ID
where it's missing and strip the payload from the log call.

Такой skill буквально описывает то, что ты обычно проверяешь глазами при ревью логов — только теперь это делает Claude, причём сразу с исправлением. Если хочешь разобраться в устройстве skills глубже, у нас есть отдельный бесплатный курс zero2claude, где эти механики разбираются с самых основ.

Где именно запускать проверку

После того как проверка оформлена в skill, нужно решить, КАК она будет срабатывать. Anthropic выделяет четыре паттерна, и у каждого своя область применения.

Standalone имеет смысл, когда проверка не нужна на каждое изменение — например, аудит лицензионных заголовков по всему репозиторию раз в неделю. Минус в том, что каждый вызов — это отдельное действие, которое нужно не забыть сделать. Если ты ловишь себя на том, что запускаешь standalone-skill после КАЖДОГО изменения — это сигнал, что процедура заслужила постоянное место: встроить её или сцепить с другой.

Embedded — когда проверка дописывается прямо в тело того skill, который создаёт артефакт. Например, к skill для скаффолдинга React-компонента можно просто добавить в конце: «после создания файла запусти eslint и исправь ошибки перед тем как отчитаться о завершении». Такой паттерн работает только для skills, которые ты контролируешь сам — свои или установленные на уровне проекта. Встроенные системные skills и те, что управляются плагинами и перезаписываются при обновлении, для этого не подходят — для них нужен паттерн chained.

Chained — когда один skill в конце вызывает следующий, и получается целая цепочка проверенных передач. В команде Claude Code внутри Anthropic именно так и работают: /code-review ищет баги, /simplify вычищает диф, /verify подтверждает поведение end-to-end, а кастомный /design проверяет соответствие гайдлайнам из DESIGN.md, если изменения касались UI. Привычка «я всегда запускаю /verify после /simplify» превращается в контракт «/simplify всегда вызывает /verify в конце». Единственный минус — цепочки увеличивают расход токенов, поэтому их стоит протестировать перед тем, как распространять на всю команду.

На каждый PR — финальный шаг, когда цепочка уже отлажена на твоих собственных изменениях. Тогда те же ворота ставятся на изменения коллег — независимо от того, вспомнили ли они сами запустить проверку. Это момент, когда верификация перестаёт быть личной инфраструктурой и становится командной: проверка, которая экономила тебе пару минут в неделю, теперь экономит эти минуты всей команде на каждом изменении. Но не стоит выставлять PR-ворота, пока цепочка ещё «плывёт» — иначе каждая правка будет видна всей команде как событие.

Пошаговый процесс

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

1. Выбери ту ручную доработку, которую ты делал чаще всего за последнюю неделю.
2. Попробуй встроенный skill /verify — возможно, он уже закроет твою задачу.
3. Опиши процедуру простым языком, как для нового коллеги в первый день.
4. Отдай текст skill-creator или сам положи markdown-файл в .claude/skills/.
5. Вызови skill на новой задаче и убедись, что проверка реально срабатывает — при необходимости доработай.
6. Поэкспериментируй с цепочками skills, чтобы получить полный end-to-end поток проверки.

Чем больше правил и проверок ты закодируешь для Claude, тем чаще его первый ответ будет попадать точно в цель. А правки, которые ты больше не делаешь вручную, освобождают внимание для той работы, которую по-настоящему не может сделать за тебя ни один skill. Если тема Claude Code в целом кажется новой — стоит посмотреть, как безопасность встраивается в такие процессы, об этом мы писали в посте про AI-native SDLC Anthropic, а про похожий подход из практики компаний — в истории Datadog про их «универсальный станок» для агентов.

Частые вопросы

Циклы верификации — это, по сути, способ передать Claude Code те же привычки, которые есть у опытного разработчика: не сдавать работу, не проверив её самому. Начни с малого — с одной повторяющейся ручной проверки на этой неделе — и постепенно вырастишь целую систему, которая работает без твоего постоянного контроля.

Если хочешь попробовать всё это руками — начни с бесплатного курса «Claude Code и терминал: с 0».