Исследовать → спланировать → написать → закоммитить

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

Зачем разделять

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

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

Возьмём задачу из практики. В Next.js-приложении интернет-магазина нужно добавить экспорт списка заказов в CSV из админки. Есть API на Node, есть таблица заказов на фронте, есть требование: экспорт должен уважать текущие фильтры таблицы.

Фаза 1: исследовать

Включите режим плана: Shift+Tab до ⏸ plan mode on или claude --permission-mode plan. Теперь агент читает, но не пишет.

прочитай app/admin/orders и api/orders. разберись, как таблица заказов
получает данные и как устроены фильтры. посмотри, есть ли в проекте
готовые утилиты для генерации файлов на скачивание.

Обратите внимание на форму запроса: вы направляете агента к конкретным папкам и говорите, что искать. Документация называет это «указать источники». Без этого агент будет исследовать вширь и потратит контекст на ненужные файлы.

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

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

Фаза 2: спланировать

Оставаясь в режиме плана, попросите план:

хочу добавить кнопку «Экспорт в CSV» в таблицу заказов. экспорт должен
учитывать текущие фильтры. какие файлы нужно изменить? как передать
фильтры на сервер? составь план.

Агент вернёт список шагов с файлами. Прочитайте его внимательно — это самый дешёвый момент для исправлений. Нажмите Ctrl+G, чтобы открыть план в редакторе и поправить руками, или ответьте «No, keep planning» и опишите, что не так: «не создавай новый эндпоинт, добавь параметр format=csv к существующему».

Для больших фич документация советует другой приём: пусть агент сначала возьмёт у вас интервью. Промпт вида «я хочу сделать X, опроси меня подробно инструментом AskUserQuestion про реализацию, интерфейс, краевые случаи и компромиссы, потом запиши спецификацию в SPEC.md». Затем — новая сессия с чистым контекстом, которая реализует спецификацию. Так проектирование и реализация не смешиваются в одном разговоре.

Когда план устраивает, примите его. Вариант «Yes, manually approve edits» оставит вам подтверждение каждой правки — для первых задач это полезно.

Фаза 3: написать

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

реализуй план. напиши тесты для генерации CSV: пустой список, заказ
с запятой в адресе, фильтр по статусу. запусти тесты и исправь падения.

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

Пока агент работает, смотрите, что он делает. Esc останавливает, если он пошёл не туда. Поправку можно и не останавливая написать — он учтёт её на следующем шаге. Если он завис на одной ошибке и уже дважды не смог её исправить, лучше остановить, сделать /clear и переформулировать задачу с учётом того, что вы увидели.

Ещё одно правило из документации: работайте небольшими шагами. Один файл — проверка — следующий файл. Ошибки на раннем этапе дешевле.

Фаза 4: закоммитить

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

закоммить с содержательным сообщением и открой PR

Claude Code умеет работать с git напрямую: смотрит diff, пишет сообщение коммита, создаёт ветку, открывает pull request через gh (для GitLab — glab). Документация советует проверить сгенерированное описание PR и попросить агента отметить риски: «дополни описание PR, объясни, как обрабатываются заказы с переносами строк в полях». Сессию, в которой создан PR, потом можно найти командой claude --from-pr <номер>.

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

Когда фазы можно пропустить

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

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

Скрипты и параллельная работа

Тот же цикл можно запускать без интерактива. Флаг -p выполняет один запрос и завершает работу:

claude -p "объясни, что делает этот проект"
claude -p "перечисли все API-эндпоинты" --output-format json

Для параллельных задач есть git worktree: claude --worktree fix-export создаёт отдельную рабочую копию на своей ветке, и второй агент в соседнем терминале не мешает первому. Для пакетной работы — цикл по файлам с claude -p и флагом --allowedTools, ограничивающим инструменты. Эти сценарии выходят за рамки вводного курса; они разобраны в документации по common workflows.