Декомпозиция: plan и tasks
Превращаем согласованную спеку в план реализации и плоский список задач в tasks.md. Как резать на инкременты по пользовательским сценариям, чтобы каждую задачу можно было проверить отдельно, и где расставлять контрольные точки для ревью (примерно каждые 3–4 задачи). Реализуем первые задачи агентом, держа его в рамках tasks.md.
Декомпозиция: plan и tasks
Спека прошла clarify-цикл — агент перестал задавать вопросы по существу. Это не черновик, а согласованный документ. Теперь превращаем его в конкретные задачи, которые агент выполняет по одной.
Два уровня: plan и tasks
Между спекой и кодом — два промежуточных артефакта.
Plan — план реализации: последовательность шагов на уровне «что делается в каком порядке». Не технические детали, а структура работы. Удобно хранить в specs/auth-login-plan.md или в отдельном разделе той же спеки.
Tasks — плоский список в tasks.md в корне проекта. Помните, в первом подмодуле мы специально оставили этот файл пустым с пометкой «появится позже»? Это тот самый момент. Каждый пункт — одна атомарная задача, которую можно выполнить и проверить независимо.
Почему два уровня? Plan позволяет проверить логику до того, как вы начнёте тикать чекбоксы. Tasks — это то, что агент исполняет. Если пропустить план и сразу писать tasks, легко пропустить зависимости или обнаружить в середине реализации, что порядок неверный.
flowchart TD
A[Согласованная спека] -->|промпт агенту| B[plan.md]
B --> C[tasks.md]
C --> D[Задача 1]
D --> E[Задача 2]
E --> F[Задача 3]
F --> G{Контрольная точка}
G --> H[Задача 4]
H --> I[Задача 5...]Просим агента составить план
После clarify-цикла переходите к планированию прямо в той же сессии. CLAUDE.md и спека уже в контексте — добавьте:
У тебя есть согласованная спека в specs/auth-login.md.
Составь план реализации: что нужно сделать и в каком порядке.
Не пиши код. Укажи зависимости между шагами.
Каждый шаг — одно изменение, которое можно проверить отдельно.Агент вернёт структуру. Проверьте её глазами: есть ли шаг, результат которого нельзя проверить? Есть ли шаг, который предполагает что-то из более позднего? Обычно достаточно одной правки — поменять порядок 1–2 пунктов.
Режьте по сценариям, а не по слоям
Самая распространённая ошибка декомпозиции — резать по техническим слоям:
❌ «Создать модели» → «Написать сервисный слой» → «Написать контроллеры» → «Написать тесты»
Каждый шаг выглядит логично, но у него нет проверяемого результата. «Модели готовы» — что это значит? Что они работают? Для чего?
Правильная нарезка — по пользовательскому сценарию. Каждая задача реализует один конкретный кейс от запроса до ответа:
✅ «POST /auth/login возвращает 200 и токен при верных данных»
✅ «POST /auth/login возвращает 401 при неверном пароле»
✅ «После 5 ошибок подряд — 429 и блокировка на 15 минут»
Каждую из них можно запустить, проверить и честно сказать «готово» независимо от остальных. Это вертикальный срез — от UI или API до базы данных по одному сценарию, вместо горизонтального разреза по технической плоскости.
Формат tasks.md
Держите файл простым — никакой иерархии, только плоский список:
# tasks.md — auth-login
## В работе
- [ ] POST /auth/login → 200 + JWT при верных данных
- [ ] POST /auth/login → 401 при неверном пароле
- [ ] POST /auth/login → 429 + блокировка после 5 ошибок подряд
## Готово
- [x] Настройка окружения и зависимостей (bcrypt, jsonwebtoken)
## Контрольные точки
- [ ] ✓ Ревью после задач 1–3Имена задач — глагол плюс конкретный результат. Не «Авторизация» — а «Хэндлер POST /auth/login возвращает токен». Если название не содержит проверяемого исхода, задача недостаточно конкретная. Можно проверить себя: если взять пункт из «Критериев готовности» спеки — он должен почти дословно лечь в tasks.md.
Контрольные точки: каждые 3–4 задачи
Примерно раз в три-четыре задачи остановитесь и посмотрите на всё вместе. Это не обязательно полноценный код-ревью: достаточно запустить проект и убедиться, что реализованные задачи работают как система, а не только по отдельности.
Контрольная точка нужна потому, что агент может правильно выполнить каждую задачу, но между ними возникает рассинхронизация — разные допущения, лишний код, пропущенная интеграция. После каждой задачи — слишком часто, после десяти — слишком поздно. Трёх-четырёх задач хватает, чтобы паттерн стал виден, но ещё не накопился долг.
Держим агента в рамках tasks.md
Когда начинаете задачу, явно указывайте агенту, что именно делаете:
Смотри specs/auth-login.md и tasks.md.
Реализуй первую задачу из раздела «В работе»:
POST /auth/login → 200 + JWT при верных данных.
Только эту задачу, не трогай остальные.Без явной привязки агент может «помочь» и начать реализовывать соседние пункты раньше времени. «Только эту задачу» — не вежливость, а ограничение контекста.
После того как агент закончил — не переходите сразу к следующей задаче. Потратьте две минуты: сверьте результат с критериями готовности из спеки (мы заполняли их в подмодуле 2). Если всё ок — отметьте чекбокс и переходите. Это маленькая петля качества, которая экономит откат на час. В следующем подмодуле мы разберём приёмку детально — там тот же принцип, но в полном масштабе готовой фичи.
Задание
Возьмите спеку из прошлых подмодулей. Запустите планировочный промпт — получите план, скорректируйте порядок. Создайте tasks.md с первыми 4–6 задачами, нарезанными по сценариям. Поставьте контрольную точку после третьей задачи. Запустите агента на первую задачу — и проверьте результат прежде, чем идти дальше.
Самопроверка
- Какая основная причина составления отдельного plan перед созданием tasks.md?
- Какой пример лучше всего иллюстрирует нарезку задач по сценариям, а не по слоям?
- Что из следующего НЕ должно быть в правильной формулировке задачи в tasks.md?
- Примерно как часто нужно ставить контрольные точки при реализации цепочки задач?
- Почему важно явно ограничивать агента одной задачей в промпте?
- Главное преимущество вертикального среза над горизонтальным в том, что:
- Когда в tasks.md нужно отмечать чекбокс как завершённый?