Между "понять" и "изменить" стоит отдельная фаза, и смешивать их - дорогая ошибка. Plan mode нужен именно для того, чтобы отделить исследование от реализации: в нём Claude читает файлы и выполняет признанные read-only shell-команды, но не меняет исходники. Включают его переключением Shift+Tab до режима Plan или командой /plan с формулировкой задачи. Результатом становится план, который вы одобряете до того, как будет тронут хоть один файл.

Важно понимать, что plan mode - это режим анализа, а не скрытой реализации. Если доступен auto mode и включён useAutoModeDuringPlan, классификатор может разрешать дополнительные команды, но суть режима не меняется: он служит пониманию, а не изменению. Это техническая гарантия того, что фаза исследования не превратится незаметно в правки, - но гарантия не отменяет необходимости ясной задачи, которую режим сам по себе не заменяет.

Хороший план узнаваем по конкретике. В нём есть наблюдаемая причина с доказательством, список файлов и symbols, которые будут изменены, последовательность изменений, вопрос миграции и обратной совместимости, тест, который сначала падает или явно фиксирует регрессию, команды проверки, условия отката и отдельно - неизвестные, требующие вашего решения. План из трёх строк "обновить сервис, добавить тест, проверить" точки контроля не даёт: по нему нельзя судить, что именно произойдёт.

Если план вышел общим, конкретику стоит запросить явно. Ниже - формулировка, которая заставляет расписать каждый шаг: точный файл, symbol, ожидаемое изменение контракта и проверку, а отдельно - предположения, ещё не подтверждённые кодом. Именно вынесенные наружу предположения важнее всего: они показывают, где план стоит на догадке, а не на прочитанном коде, и где вам, возможно, придётся вмешаться до, а не после реализации.

Принятие плана - это точка контроля направления, и её проходят осознанно. Перед переходом к записи проверяют git status; если параллельно работает другой агент, берут отдельный worktree. Затем выходят из plan mode, одобряют план и явно повторяют границы - какие шаги реализовать, чего не делать (миграцию, изменение публичной схемы) и где остановиться, чтобы показать diff. Повтор границ при одобрении дешевле, чем откат уже сделанных лишних изменений.

Полезно один раз увидеть, как выглядит одобрение плана с явными границами. Ниже - короткая формулировка: реализовать конкретные шаги, не трогать миграцию и публичную схему, остановиться после focused-тестов и показать diff. К этой форме возвращаются на каждом переходе от плана к коду: она превращает одобрение из расплывчатого "давай" в точную команду с заданными пределами.