Create a PRD

Turn the available idea, ticket, research, or pain point into a Product Requirements Document that defines what the product should do and why it matters. Keep implementation design for the downstream TDD.

Treat the PRD as a living spec: after each resolved decision, rework the affected prose and visuals so the document describes the current product coherently. It must never read like interview notes, a decision log, or a transcript.

Interview protocol

These rules govern the foundation and solution interviews:

• Ask exactly one product question per interview message. A choice among two or three options is one question; multiple independent decisions are not.
• Ask the highest-leverage unresolved question, explain the options and tradeoffs, give a recommendation, then wait. Make it a concrete decision, never a vague request for feedback.
• Keep one decision open until it is resolved. If the user pushes back, thinks aloud, or asks a clarifying question, answer within that decision and leave the PRD unchanged.
• Flush a decision only after it is settled. Rewrite every affected section in one pass; reorder or remove stale material instead of appending an answer.
• Keep questions in product space: user experience, functionality, behavior, and success. Put implementation choices such as schemas, storage, or architecture under Deferred to TDD.
• Use takeaway headings that state the conclusion, short paragraphs, and visuals beside the claims they explain.

The interview protocol is satisfied only when each interview response contains one decision and one question, and each document edit represents a resolved decision consistently everywhere it applies. The final handoff is not an interview message and follows its referenced template instead.