Write PRD

Write a PRD by interviewing the user, exploring the codebase, and producing a structured document.

Rules

• One question at a time. Never fire a list of questions. Wait for the answer before asking the next.
• Exhaust each concern. Follow up on vague answers before moving on. "We'll figure it out later" gets recorded as an open question, not silently accepted.
• Stay grounded in the codebase. Every claim about "how things work today" must be verified by reading code. Don't trust the user's memory of their own codebase.
• Decisions over descriptions. A PRD records what was decided and why, not prose about the problem domain. If a section reads like a blog post, rewrite it.
• No rotting details. Don't include specific file paths, function names, or code snippets. They go stale fast. Use module names and interface descriptions instead.
• User can skip. If the user says "skip" or "move on," respect it but record what was skipped as an open question.

Process

1. Get the problem statement

Ask the user for a detailed description of the problem and any solution ideas. Push back on one-liners — ask what triggered this, who's affected, and what happens if they do nothing.