write-prd

/write-prd - Product input -> clarified PRD

This command resolves product-level ambiguity. It does not decompose the PRD into epics/features or perform architecture/task design.

<input_contract> Require at least one current product source:

• .memory-bank/analysis/brief.md;
• legacy .memory-bank/analysis/product-brief.md or relevant .memory-bank/analysis/brainstorming/BR-*.md migration evidence;
• explicit operator-provided product or PRD text/file;
• existing prd.md or .memory-bank/prd.md being clarified.

Read .memory-bank/constitution.md. Read only relevant optional context from discovery, product/requirements, glossary/invariants, spec-backbone, spec-index, canonical contracts/states/runbooks/testing docs, and $ARGUMENTS.

Before writing, record whether prd.md or .memory-bank/prd.md already exists; this selects the handoff route.

If no product source exists, stop and request /grill-me or explicit source text. If the Constitution is missing, ask for /constitution or explicit permission to continue without ratified project principles. </input_contract>

<creator_vibe_contract> Before interpreting PRD sources or interviewing the operator, load and follow the installed creator-vibe skill. Apply it while reading the discovery brief, idea/PRD text, relevant discovery context, and operator answers so the PRD preserves the product's intended human experience and distinctive center while making behavior and acceptance explicit.

Creator-vibe is an interpretation lens, not product authority. Constitution, authoritative sources, and explicit accepted decisions still govern; inferred intent cannot fill a material ambiguity, create a requirement, or choose a branch for the operator. </creator_vibe_contract>

<hard_invariants>

• Constitution and explicit accepted operator decisions outrank lower-level product evidence.
• Do not weaken, reinterpret, or silently override the Constitution.
• Ground every material PRD claim in source evidence or an accepted answer.
• Do not create product decomposition, feature/task records, implementation plans, or SDD design specs.
• A recommendation/default is not an operator decision; silence is not consent. </hard_invariants>

<operator_decisions> Inspect the PRD for material ambiguity across these coverage areas, in any order:

• functional scope and behavior;
• users/actors and UX flows;
• domain/data model;
• non-functional qualities;
• integrations and external dependencies;
• edge cases/failure handling;
• constraints/tradeoffs and terminology;
• acceptance criteria, verification, and completion signals;
• unresolved markers such as NEEDS CLARIFICATION, TBD, TODO, or ???.

Treat a non-functional quality as material when its failure would itself block product/feature acceptance or realize a significant accepted risk. Its product basis must identify the observable quality, an accepted numeric target or qualitative success criterion, conditions that can change pass/fail, and a verification-method class. A human/expert review is valid when it names the observable qualitative criterion and reviewer type; detailed rubric/evidence design belongs downstream only when non-trivial.

Never invent or silently interpret a material target or pass/fail parameter. If authoritative sources and accepted operator decisions do not settle one, keep the existing clarification blocker and resume through /write-prd.

Ask the operator whenever a real ambiguity or branch could affect product behavior, scope, architecture, data, decomposition, testing, operations, security/compliance, or acceptance. Adapt the interview to the evidence: ask one question or a small group of tightly related questions, use multiple choice or open form, explain impact, and optionally recommend an option. Do not impose a question quota, fixed questionnaire, or short-answer word limit. Do not ask decorative questions for already-authoritative evidence.