Фича от спеки до релиза за один проход

Проведи фичу через все 7 фаз за один проход. Контекст:

• Фича: {{feature_brief}}
• Кодовая база: {{codebase_context}}
• Аудитория: {{audience}}

База: это orchestrator — один большой ответ, в котором последовательно идут 7 фаз. Каждая фаза имеет свой артефакт и checkpoint для следующей фазы. Цель — не «сделать всё идеально», а не потерять контекст между шагами, на которые иначе ушло бы 5-7 отдельных промтов с пересказом одного и того же.

Когда применять

Подходит:

• Фича размером 1-50 файлов / 100-1500 строк диффа
• Scope понятен на 80%+ (есть PRD или хотя бы внятный one-pager)
• Команда из 1-3 человек, ревью внутри 24ч
• Стек, который ты уже понимаешь (нет «параллельной» задачи разобраться с фреймворком)
• Дедлайн «к концу дня / завтра» — нужна скорость без потери качества

НЕ подходит:

• Мега-эпик (>2 недель, >50 файлов) — раздели на 3-5 фич, каждую через этот промт отдельно
• Требования размыты («сделай красиво», «улучши UX») — сначала через discovery / spec-промт
• R&D / эксперимент (не знаешь, заработает ли подход) — сначала spike branch, потом этот промт
• Migrations / breaking changes на уровне API всей компании — нужен RFC и согласование
• Хотфикс прод-инцидента — другой жанр (root cause → minimal fix → postmortem)

7 фаз orchestrator'а

Phase 1: Spec

Что: PRD-сжатый формат на одну страницу. Цель — зафиксировать, что именно строим, до того как код написан и его уже жалко выкидывать.

Структура:

• User story — одна строка: «Как {{audience}}, я хочу X, чтобы Y»
• Success criteria — 3-5 проверяемых пунктов («после релиза время на задачу N падает с 5 мин до 30 сек», «error rate < 0.1%»)
• Non-goals — что мы НЕ делаем в этой итерации (важнее, чем кажется — защита от scope creep)
• Edge cases — список 5-10 пунктов: пустой input, max length, concurrent calls, offline, права/роли, разные локали
• Open questions — то, на что нет ответа сейчас, но решение нужно до Phase 2

Output: markdown-блок ## Spec на 30-50 строк. Если open questions блокируют — стоп, спросить, не идти дальше.

Phase 2: Architecture

Что: превратить спеку в технический план. Не «диаграмма ради диаграммы», а ответы на вопросы «что трогаем», «что новое», «где риск».

Структура:

• Типы — TypeScript interface / pydantic / Go struct для главных сущностей. Конкретно, не «UserModel { ... }»
• Data flow — откуда приходит запрос → через какие слои → куда уходит ответ. 3-7 шагов
• Sequence diagram (ASCII) — для нетривиального flow (несколько сервисов / async)
• Новые файлы — список путей с одной строкой назначения каждый
• Изменения существующих — список файлов + что именно правим
• Риски + rollback plan — 3-5 рисков (производительность, миграция данных, обратная совместимость) + что делаем, если в проде что-то пошло не так (feature flag? миграция назад? откат коммита?)

Output: ## Architecture с ADR-mini (контекст / решение / альтернативы / последствия), file tree diff, sequence diagram, risks. ~60-100 строк.

Phase 3: Implementation plan

Что: разбить работу на 5-15 атомарных коммитов. Атомарный = сам по себе компилируется, тесты проходят, ревьюверу понятно за 5 минут.

Структура:

• Numbered list задач (1 → N)
• Для каждой: что меняется, какие файлы, какие тесты идут именно с этим коммитом
• Зависимости явно (#3 после #2, потому что использует тип из #2)
• Помечай задачи как [code], [test], [docs], [refactor]
• Если задача > 200 строк диффа — раздели

Output: ## Implementation plan — список вида 1. [code] Добавить тип Order в src/types/order.ts; тесты: src/types/order.test.ts (round-trip serialize). 5-15 пунктов.

Phase 4: Implementation

Что: написать код по списку из Phase 3, в том же порядке. Один коммит — одна задача.

Правила:

• Diff минимальный — не трогать unrelated файлы, даже если «там тоже плохо» (это другая задача)
• Не вводить новые зависимости без явной причины — старая зависимость, делающая 80% работы, лучше новой с 100%
• Следовать конвенциям из {{codebase_context}} (naming, exports, file structure)
• Если по ходу всплыло, что в Phase 2 ошибка — стоп, обновить Phase 2, не «фиксить на лету»

Output: ## Implementation — для каждой задачи из плана: имя файла + diff (или полный файл, если новый). Это самая длинная секция — 200-800 строк ОК.

Phase 5: Tests

Что: покрыть фичу тестами на 4 уровнях. Не «один happy path», не «100% coverage любой ценой» — а смысловое покрытие.

Уровни:

• Unit — для каждой новой чистой функции (input → output). Быстрые, без I/O
• Integration — для feature flow целиком (HTTP request → DB → response, или UI action → state → render)
• Edge cases — null, undefined, пустой массив/строка, очень большой input, concurrent calls, race conditions, timeouts
• Regression — если фича связана с прошлыми багами или меняет существующий код — тест, который сломался бы при возврате старого поведения

Output: ## Tests — тестовые файлы (полностью), + короткая таблица «что покрыто / что НЕ покрыто и почему» (например, «не покрыто: интеграция с третьим сервисом X, потому что mocking стоит дороже самого теста — оставлено на staging»).

Phase 6: Documentation

Что: обновить документацию до PR, не «потом». «Потом» = никогда.

Что обновляем:

• README delta — если фича меняет setup / запуск / конфиг — обнови README. Точечно, не «перепиши всё»
• API docs — если изменился публичный API (HTTP endpoint, exported function, CLI flag) — обнови schema/docs
• Inline comments — добавлять ТОЛЬКО для «почему», не для «что». «Что» должно быть видно из кода. «Почему» — это бизнес-причина, ссылка на тикет, неочевидное ограничение
• CHANGELOG entry — одна строка в формате проекта (Keep a Changelog / Conventional Commits)
• Migration guide — если breaking change, отдельный блок «как мигрировать»

Output: ## Documentation — список файлов с конкретными правками.

Phase 7: PR & release notes

Что: упаковать всё в PR description (для команды) и release note (для пользователя). Это разные тексты для разных аудиторий.

PR description:

• Problem — 2-3 строки, какую боль решаем (со ссылкой на тикет)
• Solution — 3-5 bullet'ов, что сделано на уровне архитектуры
• Testing — как ревьювер может проверить локально (команды, URL, тестовые данные)
• Risks — что может пойти не так, на что смотреть в первые часы после релиза
• Rollback — как откатить, если что (feature flag off / revert PR / data migration backward)
• Screenshots / GIF — если UI

Release note (для пользователя):

• One-liner в стиле продукта (не «refactored XYZ module», а «теперь N-задача занимает 30 секунд вместо 5 минут»)
• Screenshot если UI
• Кому видно — всем / behind flag / только enterprise

Output: ## PR & Release Notes — два готовых текста, можно копировать в GitHub и в changelog продукта.

Контракт между фазами

Каждая фаза заканчивается checkpoint — компактным резюме, которое явно передаётся в следующую. Это страховка от «забыл, что решили в Phase 2».

В каждой фазе первая строка — это входящий checkpoint от предыдущей. Так читающий ревью видит цепочку, не пролистывая весь ответ.

Формат вывода

В одном response — все 7 фаз последовательно, с заголовками ## Phase N: Name. Каждая фаза = один минимально полный артефакт (не «черновик», не «TODO», а то, что можно сразу положить в репозиторий или PR).

Длинный output ОК и ожидаем — это и есть смысл orchestrator'а: вместо 7 отдельных промтов с пересказом контекста получаешь один длинный, но связный.

В конце короткий блок ## Definition of Done — чек-лист на 7 пунктов («Phase N done because…»), чтобы было видно, что ничего не пропущено.

Анти-паттерны

• ❌ Прыгать сразу в Phase 4 (код) без Phase 1-3 → переделки на следующий день, когда становится ясно, что не учли edge case
• ❌ Тесты «потом добавлю» → не добавляются никогда, особенно если PR уже approved
• ❌ PR без release notes → support и marketing не знают, что отвечать пользователю; фича «есть, но как бы нет»
• ❌ Документация только в коде / в комментариях → внешние пользователи её не видят, читают только тех, кому залезть в репо
• ❌ Сразу 30 коммитов в один большой → review невозможен, ревьювер ставит approve «на доверии» и пропускает баги
• ❌ Phase 2 (arch) без рисков и rollback plan → в проде что-то ломается, откатить нечем, инцидент длится часами
• ❌ Менять Phase 1 (spec) на ходу в Phase 4 → теряется originally agreed scope, ревью становится про «а это вообще должно тут быть?»
• ❌ Пропустить checkpoint между фазами → к Phase 5 уже не помнишь, какие edge cases были в Phase 1
• ❌ Все 7 фаз для багфикса в одну строку → overkill, используй короткий root-cause-fix промт
• ❌ Делать все 7 фаз параллельно в разных вкладках → теряется именно то, ради чего этот промт нужен — единый контекст