Команда /dr-prd — требования до кода
Как /dr-prd проводит структурированное интервью по выявлению требований, прорабатывает три и более технических подхода и создаёт PRD — документ, который служит источником правды для всего пайплайна.
План, написанный без понимания задачи, — это догадка, оформленная как документ. Команда /dr-prd устраняет этот разрыв. Она проводит структурированный процесс выявления требований и создаёт Product Requirements Document — PRD, — в котором указано, что нужно построить, зачем и с какими ограничениями. Все последующие стадии пайплайна ссылаются именно на него.
Команда принимает ID задачи, назначенный на /dr-init, и проходит три фазы. Фаза 1 собирает контекст, читая существующие файлы проекта и релевантный код. Фаза 2 проводит интервью по выявлению требований и ограничений. Фаза 3 формирует сам PRD, сохраняет его и предлагает элементы бэклога для любых подзадач, обнаруженных попутно.
Что она делает
Сбор контекста в фазе 1 читает брифы проекта, технический контекст и файлы системных паттернов. Для задач уровня 2 и выше перед интервью может запускаться опциональный исследовательский проход — он порождает агента-исследователя, который ищет внешнюю документацию, поведение библиотек или прошлые находки, связанные с задачей. Результаты попадают в файл инсайтов, на который затем опирается интервью.
Интервью по выявлению требований в фазе 2 адаптируется к сложности. Быстрое интервью для простых задач задаёт целенаправленные вопросы о масштабе и ограничениях. Глубокое интервью для сложных задач исследует влияние на пользователей, границы системы и точки интеграции. Результат — структурированное резюме требований, которое напрямую питает PRD.
Фаза 3 генерирует минимум три различных технических подхода к задаче, у каждого — явные плюсы и минусы, оцениваемые по четырём критериям: безопасность, соответствие существующим паттернам, избегание дублирования и тестируемость. После того как оператор принимает решение, команда записывает PRD в datarim/prd/ и проверяет путь каждого критерия приёмки перед сохранением.
Один конкретный пример
Задача добавить rate-limiting к публичному API проходит через команду так. Фаза 1 читает существующие обработчики API и обнаруживает Redis, уже работающий в проекте. Фаза 2 спрашивает о допустимых лимитах, поведении при ошибке и нужны ли лимиты на пользователя или на IP. Фаза 3 предлагает три подхода — счётчик в памяти, скользящее окно в Redis, правило на шлюзе — и оценивает их. Скользящее окно Redis побеждает: переиспользует существующую инфраструктуру и переживает перезапуск процесса. Это решение с обоснованием попадает в PRD в раздел Technical Approach, с критерием приёмки: rate limiter возвращает HTTP 429 после заданного порога.
Место в пайплайне
Команда запускается после /dr-init для задач уровней 3 и 4. Задачи уровня 1 пропускают её полностью; уровень 2 может пропустить при несложном планировании. PRD, созданный здесь, становится эталонным документом для /dr-plan — который разбивает подтверждённый подход на шаги реализации — и для /dr-qa, проверяющего финальную реализацию против заявленных требований.
Есть и шаг слияния ожиданий. После сохранения PRD команда добавляет новые пожелания, выведенные из критериев успеха, в файл ожиданий, созданный во время /dr-init. Намерение оператора остаётся прослеживаемым от брифа до верификации — без перезаписи того, что уже было.
Общую картину даёт пост что такое Datarim; как PRD превращается в план реализации — в описании команды /dr-plan.