write-prd

Write a PRD for: $ARGUMENTS

Research the domain and the codebase, make every design decision yourself from that evidence, and write ./tasks/prd-[feature-name].md plus ./tasks/prd-[feature-name]-status.json. The run is autonomous: where a question would normally go to the user, answer it from the evidence and log the rationale, so the user reviews a finished PRD rather than a questionnaire. Stop early only when $ARGUMENTS names no feature to specify, printing Usage: /write-prd [feature description]. Explicit user instructions override anything below.

Print [Phase N/6] NAME before each phase: INTAKE, RESEARCH, DECIDE, STRUCTURE, WRITE, FINALIZE.

Phase 1: INTAKE

Extract the domain, research keywords, implied users, and implied scope. Detect the stack from its manifests, and read existing PRDs (tasks/prd-*.md, docs/prd*.md, specs/*.md) for format conventions and overlap.

Fast mode applies when the scope is likely under 3 stories (a single endpoint, config change, or isolated component): web research only in Phase 2, and one merged decision pass in Phase 3 that still covers edge cases, quality gates, and the devil's advocate.

Phase 2: RESEARCH

Research is mandatory and precedes every decision. Each helper runs from its brief in Brainstorm protocols, which carries its budget.