Команда /dr-plan — от требований к шагам реализации
Как /dr-plan переводит подтверждённый PRD в последовательный, осведомлённый о зависимостях план реализации, которому агент-разработчик может следовать без догадок.
PRD описывает, что строить. План реализации описывает, как это строить. Между этими двумя артефактами — пропасть, где хорошие намерения сталкиваются с реальностью: пропущенные зависимости, неверный порядок, необъявленные риски безопасности. Команда /dr-plan закрывает этот разрыв, превращая подтверждённые требования в конкретную упорядоченную последовательность шагов реализации.
Команда читает PRD, созданный /dr-prd, и запись задачи в tasks.md, затем строит план в трёх фазах, соответствующих Enhanced Design Process (фазы 4–6). Результат — структурированный план, записанный в файл описания задачи, организованный по фазам и шагам с явными зависимостями между ними.
Что она делает
Фаза 4 берёт технический подход, выбранный в ходе ревью PRD, и декомпозирует его на компоненты. Каждый компонент получает определение области, контракт интерфейса и список критериев приёмки. Зависимости между компонентами делаются явными: какие должны существовать раньше, чем могут быть построены другие.
Фаза 5 создаёт документ плана реализации. Документ структурирован как тонкая запись-указатель в tasks.md, ссылающаяся на отдельный файл плана; внутри — шаги реализации, краткое изложение рисков безопасности, план тестирования, стратегия отката и чеклист валидации как один из разделов. Чеклист привязывает каждый шаг к конкретной команде, имени теста или наблюдаемому поведению, подтверждающему выполнение, а критерии затем питают /dr-qa Layer 3 после реализации.
Фаза 6 валидирует технологический стек. Проверяется, что все упомянутые зависимости, инструменты сборки и переменные окружения реально существуют в рабочем пространстве, а каждая команда верификации критерия приёмки выполнима против текущей кодовой базы. Это не даёт плану ссылаться на инструмент или флаг, которого ещё нет.
Один конкретный пример
Задача добавить доставку вебхуков в сервис уведомлений даёт план из трёх фаз: сначала — эндпоинт регистрации вебхука (без зависимостей); затем — воркер доставки, читающий из очереди (зависит от модели данных фазы 1); наконец — логика повторных попыток с экспоненциальной задержкой (зависит от воркера фазы 2). У каждой фазы есть заметка о безопасности: фаза 1 проверяет валидацию входящего URL-параметра; фаза 2 — что воркер не логирует payload вебхука открытым текстом. Чеклист валидации привязывает каждую фазу к конкретному имени интеграционного теста. Агент-разработчик следует этому без догадок о порядке.
Место в пайплайне
Команда запускается после /dr-prd для задач уровня 2 и выше. Для задач уровней 3 и 4, где нужна проработка дизайна, план сигнализирует, что перед реализацией следует запустить /dr-design. Для более простых задач, не требующих дизайн-документов, план направляет прямо к /dr-do.
Команда также проверяет, что все пути и скрипты, указанные в критериях приёмки, реально существуют перед сохранением. Путь, которого ещё нет, должен быть помечен как «будет создан», чтобы ворота могли отличить намеренные результаты от фантомных ссылок. Это не даёт плану незаметно выйти из синхронизации с кодовой базой.
Общую картину пайплайна даёт пост что такое Datarim; как прорабатываются сложные архитектурные решения до начала кодирования — в описании команды /dr-design.