prd

# PRD workflow ## Usage ```text /prd <area> <feature> /prd iterate <area> <feature> /prd publish <area> <feature> /prd list [area] ``` Store the working artifact at `workspace/<area>/projects/<feature>/prd.md`. Use `context/templates/prd_template.md` and create the project directory only when the user is ready to start the PRD. ## Frame the problem Resolve these questions from available evidence or ask only for material gaps: 1. Who experiences the problem, and in what situation? 2. What happens today, including the current workaround? 3. Why does the problem matter now? 4. What measurable outcome defines success? 5. What is explicitly outside the first release? Capture raw evidence, assumptions, and unresolved questions in `notes.md`. Do not invent specificity when the evidence is weak. ## Draft the PRD - Keep the problem statement concise and sourced. - Describe the solution as the user outcome and product behavior, not an implementation design. - Use JTBD-format stories when they clarify the triggering situation and desired outcome. - Give every requirement testable acceptance criteria, including error and recovery behavior. - Include baselines and targets only when supported; label estimates and directional goals. - Separate P0, P1, later work, and explicit non-goals. - Identify dependencies and owners only when known. - Use RICE only when the inputs are credible enough to compare; show the inputs and formula. ## Review Before calling the draft complete, verify: - The user and problem are specific. - Evidence is distinguishable from assumptions. - Requirements map to acceptance criteria. - Loading, empty, error, permission, limit, and recovery states are covered where relevant. - Success metrics include measurement methods. - Non-goals and unresolved decisions are explicit. - No status, customer, metric, owner, or delivery claim is invented. Offer iteration, feasibility analysis, design specification, implementation-context export, or publishing as separate next actions. ## Iterate Update the current file instead of creating version copies. Record material choices in `decisions.md` with date, context, decision, rationale, and alternatives. Use Git history for versions. ## Export for implementation When requested, use `context/templates/cursor_context_template.md` and save `cursor-context.md` beside the PRD. Carry forward only approved requirements and label unresolved technical questions. ## Publish Publishing is optional. If the requested knowledge-base connector is available, search for an existing page and prepare a create-or-update preview. Obtain explicit confirmation before the external write. After success, add the returned page URL to the local document. If no connector is available, leave a local publish-ready draft.