Big feature? Have Claude interview you into a SPEC.md first

The requirement in your head hides a pile of unspoken decisions: technology choices, edge cases, what’s deliberately left out. Rather than letting Claude guess wrong and reworking, have it “interview” you first and distill the answers into a SPEC.md with acceptance criteria — then start building once you’ve confirmed it.

One-line answer

Steps

1. Start the interview. Use the prompt below (an English rendering of the official template), swapping in your one-sentence description for the bracketed part. Expected: Claude starts probing you with multiple-choice questions and follow-ups on technical implementation, UI/UX, edge cases, risks and trade-offs — Officialthe docs stress it will ask about the parts you “haven’t thought of yet,” which is exactly the point.
2. Answer seriously — don’t wing it. Our takeTen extra minutes in the interview saves hours of rework in implementation. For questions you can’t decide, answer “you recommend, and explain why” so the decision is made explicitly.
3. Review the SPEC.md. Once the interview has covered everything, Claude writes SPEC.md. OfficialThe bar for a good spec: self-contained (names the files and interfaces involved), states what is out of scope, and ends with an end-to-end verification step that proves the feature actually runs. The official line, in spirit: polishing the spec pays off more than supervising the implementation.
4. Confirm, then implement in a new session. OfficialOnce the spec is final, start a separate session to execute it: clean context, fully focused on implementation. Our takeHave the implementation prompt reference @SPEC.md directly, and require delivery phase by phase as the spec lays out — run each phase’s acceptance criteria before moving on to the next.
5. Pair complex changes with plan mode. OfficialDuring implementation you can use plan mode (toggle with Shift+Tab — the status bar shows plan mode on — or launch with claude --permission-mode plan) to get an implementation plan first, edit the plan right in your editor with Ctrl+G, and only touch code after approval. For the full explore→plan→code rhythm, see D5 · the plan mode lesson.
6. Close out by verifying against the spec. Our takeHave a subagent that took no part in the implementation compare the diff against SPEC.md and call out the gaps (see adversarial review); for how to design the verification itself, see give it checks it can run itself.

Copy-paste prompt

I want to build [one-sentence description of the feature]. Use the AskUserQuestion tool to interview me in detail:
ask about technical implementation, UI/UX, edge cases, risks, and trade-offs; skip the obvious questions
and dig into the hard parts I probably haven't considered. Keep asking until everything is covered, then write
the complete spec into SPEC.md. It must include: the files and interfaces involved, what is explicitly
out of scope, a phased implementation plan with runnable acceptance criteria for each phase
(which commands to run and what output counts as passing), and finally an end-to-end verification step.
Show it to me for confirmation when done — do not change any code before I confirm.

Once the spec is confirmed, send this in a new session:

Implement phase 1 per @SPEC.md. When done, run that phase's acceptance criteria and paste the results.
Once everything passes, stop and wait for my confirmation — do not start the next phase on your own.

Sources & last verified

• OfficialBest practices — Let Claude interview you / Explore first, then plan, then code — the interview prompt template, SPEC.md, fresh-session execution, what makes a good spec; fetched 2026-08-05.
• OfficialCommon workflows — Plan before editing — how to enter plan mode and the approval flow; fetched 2026-08-05.
• Last verified: 2026-08-05 · volatility: low (mostly methodology; only names like AskUserQuestion and plan mode are product-bound).