Реализация в Claude Code выигрывает от той же дисциплины, что и ручная работа над багом: сначала минимальный сигнал, потом расширение области. Для исправления ошибки предпочтительна последовательность - воспроизвести ошибку, сохранить падающий вывод, изменить минимальный участок, повторить тот же сигнал, прогнать ближайшие regression-тесты, затем typecheck, lint и build по необходимости, проверить diff и лишь в конце - реальное поведение. Каждый шаг опирается на предыдущий, а не прыгает к финалу.
Ключевой ход - не просить сразу "запусти всё", если suite идёт час. Сначала берут focused-сигнал: один тест, воспроизводящий проблему, который после фикса должен позеленеть. Только убедившись, что целевое поведение исправлено, расширяют проверку на соседние тесты и общий прогон. Обратный порядок - гонять весь набор на каждый шаг - тратит время и размывает сигнал: непонятно, что именно починилось, а что сломалось попутно.
Проверка diff - отдельный шаг, и просить надо не похвалу, а самопроверку против контракта. Команда /diff показывает изменения, после чего агента просят сравнить diff с исходными границами задачи: найти лишние изменения, непокрытые ветви, изменение публичного поведения и assertions, которые проходят даже при возврате старой ошибки. Последнее особенно важно - тест, зелёный и на сломанном коде, не доказывает ничего, и такой diff надо ловить до, а не после merge.
Инструменты review различаются глубиной и стоимостью, и их стоит различать. /code-review проверяет текущий diff или переданный PR на баги корректности и упрощения, а глубину задаёт режим - от low до max; /review - его алиас, а не более лёгкая команда. Режим ultra - это облачный multi-agent обзор с отдельными условиями доступности. Флаг --fix применяет найденное и потому меняет код, требуя повторного review, --comment постит комментарии. Отдельно стоит /security-review - сфокусированный security-обзор diff.
Полезно один раз свести команды review в таблицу, чтобы выбирать инструмент под задачу, а не гонять самый тяжёлый всегда. Ниже - карта: от быстрого single-pass до облачного multi-agent и security-обзора. К ней возвращаются, решая, нужен ли беглый взгляд на PR, глубокий разбор или проверка безопасности - и помня, что обзор от той же модели не является независимым доказательством.
| Команда | Что делает |
|---|
| /code-review [low..max] | Обзор diff/PR, глубина - по режиму |
|---|---|
| /review | Алиас /code-review, а не отдельная команда |
| /code-review --fix | Применяет найденное - меняет код, нужен повторный обзор |
| /code-review ultra | Облачный multi-agent обзор (отдельная доступность) |
| /security-review | Сфокусированный security-обзор diff |
Именно это ограничение стоит держать в голове: review от той же модели полезен для поиска пропусков, но не заменяет тест, статический анализатор и человека, ответственного за merge. Модель, написавшая код, и модель, его проверяющая, разделяют одни и те же слепые пятна. Поэтому review - это ещё один слой внимания, а не финальная печать: доказательством остаётся прошедший тест и наблюдение реального поведения, а не согласие агента с самим собой.
Наблюдение продукта закрывают команды /run и /verify. /run запускает приложение и пытается увидеть изменение в работе, а /verify подтверждает конкретное изменение через сборку, запуск и наблюдение. Если Claude не знает, как запустить проект из чистого состояния, генератор проектного skill создаёт навык с шагами setup и observation. Критерий формулируют конкретно: какой сценарий пройти, что должно измениться ровно один раз, какие ошибки консоли недопустимы.
# Наблюдение продукта с конкретным критерием
/verify Открой checkout, добавь два товара, обнови количество одного и убедись,
что subtotal и total меняются ровно один раз, без duplicate network request.
Сохрани наблюдения и console errors.Замыкает цикл структурный отчёт вместо общих фраз. Хороший итог называет корневую причину, изменённые файлы и назначение каждого изменения, команды в порядке запуска с кодами возврата, что проверено через реальное приложение, что проверить не удалось, и риски с рекомендуемым human review. Типичный провал реализации - принять зелёный тест на непроверенном поведении или "запустить всё" вместо focused-сигнала; правильный ход - минимальный сигнал, проверка diff против контракта и наблюдение продукта.