Convert an underspecified request into (1) a one-paragraph problem statement, (2) a scoped spec, and (3) a phased implementation plan — each shown to the user for sign-off before moving on. Never jump to code from a vague prompt.
When to use
- The request is a goal, not a specification ("build a dashboard", "add auth").
- Requirements, constraints, or success criteria are missing or implied.
- The user is exploring whether something is worth building.
Do not use this for well-specified tasks, bug fixes with a clear repro, or mechanical changes — those go straight to implementation.
Procedure
1. Restate the problem (before asking anything)
Write one paragraph: who has what problem, why now, and what "solved" looks like. Show it. If you can't write it, you don't understand the request — that gap is your first question.
2. Ask only decision-changing questions
Batch 3–6 questions that would change the design if answered differently. Skip anything with a safe default — state the default instead and move on. Good targets:
- Scope boundaries (what is explicitly out)
- Hard constraints (stack, deadline, data, compliance)
- Success criteria (how we'll know it works)
- The one assumption that, if wrong, wastes the most work
3. Write the spec
## Problem
## Goals / Non-goals
## Constraints
## Approach (1–3 sentences)
## Open questions
Keep it under one screen. Show it, get explicit "yes" on Goals/Non-goals before planning.
4. Write the phased plan
Break into phases that each deliver something verifiable:
Phase 1: <smallest end-to-end slice that proves the approach> — verify by <X>
Phase 2: ...
Each phase: concrete deliverable, the files/areas touched, and how it's verified. Flag dependencies and the riskiest phase. Front-load risk.
5. Hand off
Output the spec + plan as the final artifact. Recommend the first phase and stop — implementation is a separate step the user triggers.
Quality bar
- Problem statement fits in one paragraph and names a real user.
- Non-goals are explicit (a spec with no non-goals is not scoped).
- Every phase is independently verifiable.
- No question asked that has an obvious default.
- Zero code until the spec is signed off.
Anti-patterns
- Asking 15 questions when 4 decide the design.
- "Phase 1: set up the project" with no verifiable outcome.
- Restating the user's prompt back as if it were a spec.
- Designing the gold-plated version before the wedge is agreed.