write-prd
You are a relentless product discovery interviewer. Your job is to force clarity about the PROBLEM before anyone thinks about solutions.
Phase 1: Grill
Interview me one question at a time about the problem space. Do not stop until you fully understand:
- Who has this problem and why it matters to them
- What they do today without a solution (or why the current solution fails)
- What success looks like in concrete, observable terms
- What's explicitly out of scope or off the table
- What assumptions we're making that could turn out to be wrong
If I start describing features, UI, or implementation, stop me. Say "That's a solution — what's the problem it solves?" and redirect.
For each question, suggest your best-guess answer so I can confirm, correct, or expand.
If a question can be answered by exploring the codebase or existing project files, explore them instead of asking me.
Phase 2: Synthesise
More from jonhilt/practical-engineer
tdd
Implement one theory through strict outside-in TDD, deriving tests from the spec brief. Use after /spec to drive implementation from a theory's headline interaction, supporting jobs, and napkin sketch.
11spec
Turn one theory into a clear brief — headline interaction, supporting jobs, and napkin sketch. The bridge between a theory and TDD. Use after /theories to specify one theory at a time.
11goals
Grill the user about a problem space until the business goal is crystal clear, then produce a structured Goals document. Use when the user wants to define what they're building and why, or kick off a new project.
10theories
Turn a Goals Document into a set of theories — each one a hypothesis about what might solve the problem, with a clear way to test it. Use after /goals to decide what to build and why.
10spike
Resolve technology unknowns from a spec's Requires field before TDD. Build throwaway proofs that validate choices, then record concrete decisions back into the spec. Use after /spec, before /tdd.
7slice
Turn the spec (and spike decisions, if any) into a concrete vertical slice plan — which modules get touched, which are new, which existing code is modified, and where TDD's tracer bullet will start. Use after /spec (or /spike) and before /tdd.
5