Вся глава была подготовкой к этому уроку. По отдельности вы знаете каждый инструмент: /context, /clear и /compact, возврат к сессиям и ветвление, CLAUDE.md, разбиение на этапы. Но знать инструмент и выбрать его, когда решение неочевидно, — разные вещи.

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

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

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

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

• Как разложить CRUD-модуль на этапы, укладывающиеся в контекст
• Как формулировать фазу исследования, чтобы она не съела окно
• Что записывать в спецификацию, а что в CLAUDE.md
• Когда между этапами чистить контекст, а когда сжимать
• Как встроить проверку, чтобы агент замкнул цикл сам

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

• CRUD-модуль — набор операций над сущностью: создание, чтение, обновление и удаление, с маршрутами, валидацией и тестами.
• Опорный модуль — часть проекта, по образцу которой строится новая; здесь модуль товаров.
• Этап — часть работы, помещающаяся в контекст и заканчивающаяся проверяемым результатом.
• Критерий готовности — проверка с однозначным ответом, доступная агенту без вас.

Постановка и разведка

Исходная точка: проект интернет-магазина с рабочим модулем товаров. Нужен модуль категорий — с теми же операциями, структурой и дисциплиной тестирования.

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

Начинаем с разведки в режиме планирования — формулировка узкая намеренно:

# Shift+Tab до режима планирования
> Прочитай src/products и опиши устройство модуля: где маршруты,
  где валидация, где слой работы с БД, как оформлены ошибки
  и как организованы тесты. Не читай ничего за пределами
  src/products и его тестов.

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

Спецификация вместо разговора

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

Просим агента сначала расспросить нас: на CRUD-модуле половина решений не про код, а про поведение системы.

> Мне нужен модуль категорий по образцу модуля товаров.
  Подробно расспроси меня, прежде чем писать план: техническая
  реализация, крайние случаи, компромиссы. Не задавай очевидных
  вопросов. Затем запиши спецификацию в SPEC-categories.md:
  какие файлы создать и изменить, разбивка по этапам,
  раздел "Вне объёма работ" и раздел "Проверка".

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

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

Здесь же второе решение — что записать в CLAUDE.md, а что в спецификацию. В спецификацию идёт относящееся к этой задаче, в CLAUDE.md — действующее всегда.

# CLAUDE.md — постоянное, действует во всех задачах
- Один тест: `npm test -- --testNamePattern="<имя>"`
- Полный набор идёт 8 минут, запускать только перед коммитом
- Обработчики маршрутов не содержат логики работы с БД,
  она выносится в слой репозитория

Агент не выведет это из кода сам, а понадобится оно в каждой сессии.

Разбиение и выполнение

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

Мысль контринтуитивная: только что проделана содержательная работа, и её жалко. Но её ценность уже в файле, а в контексте остались лишь черновики интервью.

> /clear
> Прочитай SPEC-categories.md и реализуй этап 1: модель категории
  и слой репозитория. Прогони тесты этапа 1 из раздела "Проверка"
  и доведи их до зелёного. Покажи вывод команды.

Разбивка CRUD-модуля обычно такая:

1. Модель и репозиторий. Критерий: тесты репозитория зелёные.
2. Валидация. Критерий: тесты на пустое название, длину и дубликат.
3. Обработчики и маршруты. Критерий: интеграционные тесты всех операций.
4. Поведение при удалении. Критерий: тесты сценария с привязанными товарами.

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

Решения между этапами

Самое полезное здесь — развилки, возникающие в промежутках.

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

> /clear
> Прочитай SPEC-categories.md, этапы 1-2 уже реализованы.
  Реализуй этап 3 и прогони его тесты.

Внутри длинного этапа. Ситуация обратная: разговор нужен, потому что вы уточняли поведение по ходу. Подходит /compact с фокусом:

> /compact сфокусируйся на решениях по валидации категорий
  и на текущем состоянии тестов

Развилка в подходе. Вопрос вроде «хранить дерево через parent_id или через материализованный путь» — случай для /branch. Ответвьте разговор, попробуйте вариант, при неудаче вернитесь к оригиналу через /resume.

Две неудачные попытки подряд. Признак засорённого контекста. Помогает /clear с новым точным промптом, вобравшим то, что вы поняли из неудач.

> /clear
> В src/categories/repository.ts запрос дочерних категорий возвращает
  дубликаты при глубине больше двух. Пробовали чинить через DISTINCT —
  не помогло, потому что дублируются строки соединения, а не результаты.
  Начни с самого рекурсивного запроса.

Структура промпта: симптом, место, отвергнутый подход с причиной отказа, направление. Дороже по времени написания, чем «почини дубликаты», и заметно дешевле по итогу.

Приёмка

Когда этапы пройдены, остаётся сверка результата с планом — отдельным запросом, а не глазами.

> Сверь реализованный модуль категорий с SPEC-categories.md.
  Проверь, что реализован каждый пункт, что на перечисленные
  крайние случаи есть тесты и что ничего вне объёма работ
  не добавлено. Сообщай о расхождениях, а не о стилевых предпочтениях.

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

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

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

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

• Сколько этапов должно быть в CRUD-модуле? — Обычно от трёх до пяти. Ориентир не в числе, а в том, чтобы этап проходил без автосжатия и заканчивался проверяемым результатом.
• Что делать, если этап не уместился? — Сжать с фокусом на текущем этапе и продолжить по спецификации. К следующему разу разбейте этот этап на два.
• Обязательно ли писать CLAUDE.md до начала? — Не обязательно, но полезно: команды тестов и архитектурные соглашения нужны на каждом этапе и переживут любую очистку контекста.
• Можно ли делать этапы параллельно в разных сессиях? — Технически да, если они не пересекаются по файлам. Но CRUD-этапы обычно зависят друг от друга, выигрыша не будет.
• Что если спецификация получилась большой? — Это нормально: она читается по мере надобности, а не загружается постоянно. Ограничение размера относится к CLAUDE.md.

Итоги

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

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