PRD Creation

PRD Creation создаёт долговечный, основанный на доказательствах Product Requirements Document (PRD) для продуктовой проблемы, функции, изменения, API, страницы, модуля или системы. Workflow фиксирует, что известно и неизвестно, почему выбраны решение и границы, как будут приниматься требования и готов ли результат к отдельно авторизованной дальнейшей работе.

Workflow не объявляет PRD полным только из-за наличия заголовков или фиксированного числа записей. Строгий JSON-контракт отклоняет структурно неполные данные, а независимое файловое ревью проверяет текущие доказательства, трассируемость, смысл, готовность и точное соответствие канонического JSON читаемому Markdown. Каждое блокирующее замечание направляется в repair и затем на повторное ревью; до выдачи доходит только результат с нулём замечаний.

Когда использовать

Выбирайте PRD Creation, когда требуемый результат — проверенные продуктовые требования, а не реализация или специализированный дизайн.

Потребность	Workflow
Проблема, scope, требования, acceptance criteria, метрики и готовность с доказательствами	PRD Creation
User journeys, состояния интерфейса, accessibility и experience design	UX Design
Технические границы, интерфейсы, компоненты и архитектурные решения	Architecture Design
Основанная на рисках стратегия проверки и запланированные test cases	Test Planning
Исполняемые тесты из утверждённых требований	Test Generation
Реализация вместе с тестами, документацией, ревью и delivery gates	Software Development Flow

Запуск

Используйте квалифицированное публичное имя workflow:

mcp__moira__start({ action: "prepare", workflowId: "moira/prd-creation", parentExecutionId: "none" })
mcp__moira__start({ action: "execute", startAttemptId: "<ID попытки запуска из prepare>" })

Если оркестрационный workflow запускает PRD Creation как дочерний, он также передаёт собственный execution ID в parentExecutionId. Это сохраняет связь parent-child, но не расширяет полномочия дочернего workflow.

Входные данные и доказательства

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

Автор обязан исследовать доступные факты, а не угадывать. Недостающие сведения остаются явными evidence gaps, assumptions, open questions, limitations либо фактическим блокером. Запрещено выдумывать источники, цитаты, аналитику, baseline, target, поведение конкурентов и записи только ради достижения количества.

Процесс

flowchart LR
    A[Автор создаёт канонический PRD и Markdown] --> B[Независимое файловое ревью]
    B --> C{Блокирующих замечаний = 0?}
    C -- Да --> D[Выдать принятый PRD]
    D --> E[Конец]
    C -- Нет --> F[Исправить подтверждённые дефекты]
    F --> B

Workflow использует одну traversal-safe относительную папку ./moira-ws/prd-creation-<suffix>. Суффикс начинается с буквы или цифры и содержит только буквы, цифры, подчёркивания и дефисы. Вложенные пути и traversal-сегменты engine отклоняет до передачи авторских данных в ревью.

Долговечные артефакты

Артефакт	Назначение
`prd-requirements.md`	Запрошенный scope, ссылки на доказательства, пробелы, applicability decisions, assumptions и существенные неизвестные
`prd-standards.md`	Применённые стандарты, общие для автора, reviewer и repair
`prd.contract.json`	Канонический структурированный PRD и источник истины для общих полей
`prd.md`	Читаемая проекция полного контракта с обоснованиями и ограничениями
`review.md`	Полный текущий набор воспроизводимых блокирующих замечаний

Результат workflow возвращает только путь к workspace и ограниченную по размеру сводку с принятым PRD, готовностью и ограничениями. Полный PRD остаётся в файлах и не копируется через состояние workflow.

Контракт PRD

Канонический контракт включает:

источники доказательств и явные evidence gaps;
problem statement, target users, urgency и cost of inaction;
описание и обоснование решения, alternatives, in/out scope, constraints, dependencies и previous attempts;
приоритизированные требования со ссылками на доказательства и наблюдаемыми acceptance criteria;
user stories, связанные с ID требований и acceptance criteria;
релевантные edge/error cases, ожидаемое поведение и recovery;
primary metric с baseline, target, measurement method, timeframe и ссылками на доказательства и требования, а также необязательные secondary metrics;
assumptions с проверкой и последствиями, risks с likelihood, impact и mitigation;
applicability decisions, open questions, limitations, readiness и её обоснование.

Массивы ограничены по размеру, но не являются целевыми квотами. Необязательные области могут быть пустыми, когда они действительно неприменимы. Обязательные основные области должны содержать подтверждённый материал; если существенный факт нельзя получить честно, автор останавливается на блокере, а не выдумывает запись.

Гарантия review и repair

Независимый reviewer напрямую читает все текущие артефакты и релевантные первичные доказательства. Он проверяет поддержку доказательствами, честные пробелы, применимость, стабильность и уникальность ID, все перекрёстные ссылки, согласованность проблемы и решения, наблюдаемость acceptance criteria, релевантность edge/recovery, измеримость метрик, неопределённости, готовность, равенство JSON-to-Markdown и границы полномочий.

Неподтверждённые утверждения, выдуманное наполнение, битые или дублирующиеся ID, потеря структурированных данных, необоснованные пропуски, расплывчатая приёмка, неизмеримый успех, скрытая существенная неопределённость и расширение полномочий блокируют выдачу. Ненулевой счётчик ведёт в repair: он исправляет канонический источник или поясняющие доказательства, заново создаёт Markdown и возвращается к тому же reviewer. prd-standards.md можно менять только для подтверждённого дефекта самого файла стандартов; ослаблять стандарт ради обхода замечания запрещено.

Граница полномочий

PRD Creation может изучать разрешённые доказательства и записывать только локальные PRD-артефакты. Он не:

реализует продукт и не меняет проектный код или документацию;
запускает тесты и не использует version control;
публикует и не загружает артефакты;
отправляет уведомления;
деплоит и не администрирует системы.

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

Результат

Успешное завершение возвращает:

workspace_path — безопасную папку с принятыми артефактами;
result_summary — ограниченную сводку проблемы, выбранного scope, готовности, primary metric, пути к долговечному PRD и оставшихся ограничений.

Канонический контракт и счётчик review намеренно не входят в terminal projection.

Связанное

UX Design — спроектировать пользовательский опыт после достаточного определения требований
Test Planning — создать проверенный risk-based test plan без запуска тестов
Test Generation — создать исполняемые тесты из утверждённых требований
Software Development Flow — реализовать принятые требования в полном жизненном цикле репозитория
Обзор шаблонов — сравнить все публичные шаблоны