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

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

Что уже умеем / что добавим

Вы умеете измерять контекст, освобождать его через /clear и /compact, возвращаться к сессиям и ветвить их, выносить постоянные правила в CLAUDE.md. Теперь соберём из этих инструментов процесс: цикл «исследование — план — реализация — проверка», письменную спецификацию как опору между сессиями и список задач агента.

Что вы узнаете в рамках статьи

• Почему крупная задача одним промптом даёт худший результат
• Как устроен цикл «исследование, план, реализация, проверка»
• Зачем выносить план в файл проекта
• Что такое список задач агента и как он ведёт себя при сжатии
• Как дать агенту способ самому проверить работу

Ключевые термины

• Режим планирования — режим, в котором Claude исследует код и предлагает план, не изменяя файлы. Переключается сочетанием Shift+Tab.
• Спецификация — документ с планом работ, лежащий в файле проекта и служащий опорой при переходе между сессиями.
• Список задач — чек-лист агента для планирования многошаговой работы, с отметками о выполненном, текущем и предстоящем.
• Ctrl+T — сочетание, переключающее отображение списка задач в области статуса.
• Критерий проверки — то, что даёт однозначный ответ «работает или нет»: тесты, код возврата сборки, вывод линтера.

Почему крупная задача не решается одним промптом

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

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

Отсюда принцип: крупная задача разбивается не потому, что агент не справится с логикой, а потому, что не справится один контекст. Разбиение на этапы, укладывающиеся в окно с запасом, снимает проблему в корне.

Цикл из четырёх фаз

Рабочая схема состоит из четырёх фаз, и первая — не написание кода.

Исследование. Переключитесь в режим планирования сочетанием Shift+Tab: Claude читает файлы и отвечает на вопросы, не трогая исходники. Задача фазы — понять, как устроено то, что вы собираетесь менять.

# режим планирования
> Прочитай src/products и разберись, как устроен CRUD для товаров:
  где лежат маршруты, где валидация, как оформлены обработчики ошибок

План. Не выходя из режима, попросите разложить работу на шаги.

> Мне нужен аналогичный модуль для категорий. Какие файлы нужно
  создать и изменить? Составь план по шагам.

Реализация. Выйдите из режима планирования и дайте команду выполнять план — обязательно с проверкой.

> Реализуй шаги 1-3 из плана. Напиши тесты на обработчики,
  запусти их и исправь падения.

Проверка. Убедитесь, что результат соответствует плану, а не только выглядит правдоподобно.

У планирования есть накладные расходы, и на мелкой правке оно мешает. Ориентир: если изменение описывается одним предложением — планировать не нужно. Оно окупается на нескольких файлах, при неуверенности в подходе или незнакомом коде.

План в файле, а не в переписке

План, изложенный только в разговоре, живёт в истории сообщений — значит, попадёт под сжатие и потеряет детали ровно тогда, когда работа дойдёт до последних шагов.

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

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

> Я хочу построить модуль категорий. Подробно расспроси меня об этом.
  Спрашивай про техническую реализацию, крайние случаи и компромиссы.
  Не задавай очевидных вопросов, копай в сложные места.
  Когда закончим, запиши полную спецификацию в SPEC.md.

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

Дальше ключевой ход: спецификацию пишем в одной сессии, а выполняем в новой.

> /clear
> Прочитай SPEC.md и реализуй раздел 1. После реализации
  запусти тесты из раздела "Проверка" и доведи их до зелёного.

Новая сессия начинается с чистым окном, отданным реализации, а смысл задачи лежит в файле, который никуда не денется.

Список задач агента

При многошаговой работе Claude может вести чек-лист: пункты с отметками о том, что сделано, что выполняется сейчас и что впереди. Это инструмент планирования агента, а не ваш список дел.

Отображение переключается сочетанием Ctrl+T — список показывается в области статуса, до пяти пунктов сразу. Если пунктов нет, нажатие ничего не покажет. Управлять списком можно словами: «покажи все задачи», «очисти все задачи».

Одно свойство прямо связано с темой главы: пункты списка переживают сжатие контекста. Именно это делает список полезным на длинной работе — после свёртки истории агент по-прежнему видит, на каком шаге находится.

Поведение зависит от модели. Новые модели удерживают ход многошаговой работы без письменного чек-листа, и Claude Code не даёт им инструменты для его ведения, так что список остаётся пустым. Это не поломка: определения инструментов сами занимают контекст. Чек-лист включается принудительно переменной окружения:

CLAUDE_CODE_ENABLE_TODO_TOOLS=1 claude

Не путайте его с командой /tasks: она показывает другое — запущенные фоновые процессы.

Дайте агенту способ проверить себя

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

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

# Слабо: критерия готовности нет
> Реализуй валидацию названия категории

# Сильно: критерий встроен в постановку
> Реализуй валидацию названия категории: пустая строка отклоняется,
  длиннее 64 символов отклоняется, дубликат внутри родителя отклоняется.
  Напиши тесты на все три случая, запусти и доведи до зелёного.

Просите доказательства, а не утверждения: вывод тестов, выполненную команду и её результат. Читать доказательство быстрее, чем перепроверять работу самому.

Частые ошибки

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

Наиболее частые вопросы

• Насколько мелко дробить работу? — Так, чтобы этап помещался в окно с запасом и заканчивался проверяемым результатом. Ориентир — этап, который агент проходит без срабатывания автосжатия.
• Планировать нужно всегда? — Нет. Если изменение описывается одним предложением, планирование добавляет только накладные расходы.
• Почему список задач пустой? — Скорее всего, вы на модели, которая ведёт многошаговую работу без письменного чек-листа. Включается переменной CLAUDE_CODE_ENABLE_TODO_TOOLS=1.
• Обязательно ли выполнять план в новой сессии? — Не обязательно, но полезно: чистое окно целиком отдано реализации, а смысл задачи хранится в файле.
• Что делать, если этап не уместился в контекст? — Сжать с фокусом на текущем этапе и продолжить, опираясь на файл спецификации. В следующий раз разбейте мельче.

Итоги

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

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