D3.4’s plan mode is one phase of a larger loop. This chapter is the loop itself — how an architect drives a task from understanding to a committed change, refining as they go. These are disciplines, not features: the explore-plan-implement-commit rhythm, the interview pattern, and test-driven prompting outlast any particular keybinding or tool name, which is why this chapter is a stable principle rather than a feature surface.

Do I know this already? Diagnostic

Answer these confidently and you can skim ahead to Exam essentials; if any is shaky, read closely — each is developed below.

Name the four phases of the recommended workflow, in order. When is it safe to skip the plan phase?
In the interview pattern, who asks the questions, which tool drives them, and what artifact ends the interview?
Why does a fresh session implement the spec rather than the one that ran the interview?
What is described as “the single highest-leverage thing you can do,” and what does withholding it cost?
You have corrected Claude three times on the same issue this session. What is the recommended move, and why?

Check your answers

Explore → Plan → Implement → Commit; skip the plan phase only when the diff is one-sentence-describable.
Claude asks the questions, driven by the AskUserQuestion tool, and the interview ends by writing a complete spec to a file (e.g. SPEC.md).
The interview session is full of question-answer thrash; the fresh session starts on clean context whose only input is the written spec.
A verification criterion — tests, screenshots, or expected outputs so Claude can check itself; without one it “might produce something that looks right but actually doesn’t work,” and you become the only feedback loop.
Past two corrections on the same issue the context is cluttered with failed approaches — run /clear and start fresh with a more specific prompt that incorporates what you learned.

The four-phase rhythm

Letting Claude jump straight to coding produces code that solves the wrong problem; the antidote is a phased loop. “The recommended workflow has four phases: Explore [plan mode, read files] → Plan [create detailed implementation plan] → Implement [switch out of plan mode, verify against plan] → Commit [descriptive message + PR].” [Official] Best practices for Claude Code · AnthropicT1-official original Explore and Plan are the read-only front half (D3.4’s plan mode is exactly this); Implement and Commit are where edits land. Skip the plan phase only when the diff is one-sentence-describable. [Official] Best practices for Claude Code · AnthropicT1-official original

The interview pattern

For a large feature with an unclear design space, the most effective opening is to invert the usual flow and let Claude drive the questions: “For larger features, have Claude interview you first. Start with a minimal prompt and ask Claude to interview you using the AskUserQuestion tool. Claude asks about things you might not have considered yet, including technical implementation, UI/UX, edge cases, and tradeoffs.” [Official] Best practices for Claude Code · AnthropicT1-official original The interview ends by writing a complete spec to a file, and then a fresh session implements from that spec — the interview session is full of question-answer thrashing, while the implementation session starts with clean context whose only input is the written spec.

The spec file is the bridge between the two sessions: a deliverable you can review and the context bootstrap the implementation session reads.

The interview pattern, end to end Worked example

You need a rate limiter for an API and the design space is fuzzy. Instead of writing a full spec you do not yet have, you run the interview pattern:

Minimal prompt. “I need a rate limiter for our API. Interview me with AskUserQuestion before writing any code — dig into the hard parts I might not have considered, then write a complete spec to SPEC.md.”
Claude interviews you. It asks what you would not have front-loaded: Algorithm — token bucket (allows bursts) or sliding window (smoother)? Scope — per-API-key, per-IP, or global? On exceed — reject with 429, or queue and delay? Storage — in-process, or Redis so it holds across instances? Failure mode — if the limiter’s backing store is down, fail open or fail closed?
You answer, and the hard tradeoffs surface before any code — the fail-open/closed question alone is one most one-shot prompts never raise.
Artifact. Claude writes SPEC.md: token bucket, per-key, 429 on exceed, Redis-backed, fail-closed. You read and correct it — it is a reviewable deliverable, not buried in chat.
Fresh session implements. You /clear (or open a new session) and prompt: “Implement the rate limiter per SPEC.md; write the tests first.” The implementation session starts on clean context whose only input is the reviewed spec — none of the interview’s question-answer thrash.

Why the split matters: the interview session’s context is full of half-formed options and back-and-forth; the implementation session should not inherit that noise. The spec file is the clean hand-off — review gate and context bootstrap in one.

Give Claude a way to verify its work

The highest-return habit in the whole loop is supplying a success criterion: “Include tests, screenshots, or expected outputs so Claude can check itself. This is the single highest-leverage thing you can do. … Without clear success criteria, it might produce something that looks right but actually doesn’t work.” [Official] Best practices for Claude Code · AnthropicT1-official original This is also what turns a vague prompt concrete — “the build is failing” becomes “the build fails with this error: [paste]; fix it, verify the build succeeds, and address the root cause.” Test-driven prompting is the same instinct formalized: for a bug, ask for “a failing test that reproduces the issue, then fix it”; for longer work, have Claude write the tests first and keep them as the persistent contract. [Official] Best practices for Claude Code · AnthropicT1-official original

Course-correct early — and know when to restart

Iteration only pays if the loop stays clean. “The best results come from tight feedback loops” — correct Claude quickly rather than letting a wrong direction run. But there is a threshold: “If you’ve corrected Claude more than twice on the same issue in one session, the context is cluttered with failed approaches. Run /clear and start fresh with a more specific prompt that incorporates what you learned. A clean session with a better prompt almost always outperforms a long session with accumulated corrections.” [Official] Best practices for Claude Code · AnthropicT1-official original

The hands-on mechanics of this loop — the session rhythm turn by turn, and the dedicated treatments of the interview pattern and the testing discipline — are the handbook’s territory: see the Use book, Chapter 3, Your First Working Session, with the interview-pattern and testing-and-verification chapters forthcoming there.

Practice

Exercise solutions

Solution ↑ Exercise

B. A large feature with an unsettled design space is the documented home of the interview pattern: a minimal prompt asks Claude to interview you via AskUserQuestion, surfacing edge cases and tradeoffs you have not considered, and the interview ends in a SPEC.md that a fresh session then implements from clean context. A assumes you already hold a complete spec — but the premise is that you do not, so you would be encoding gaps as requirements. C burns turns thrashing and pollutes context with half-formed direction. D is the closest miss: plan mode (D3.4) makes Claude explore the code, but the interview pattern makes Claude interrogate you about intent and tradeoffs — and here the unknowns live in your requirements, not in the codebase. The interview elicits the spec; plan mode would plan against a spec you have not written yet.

Solution ↑ Exercise

The four phases in order are Explore → Plan → Implement → Commit — explore (read-only / plan mode) builds understanding, plan writes a detailed implementation plan, implement switches out of plan mode and verifies against that plan, and commit writes a descriptive message and PR. You may skip the plan phase only when the diff is one-sentence-describable — a change small and clear enough that there is nothing for a plan to de-risk.

Solution ↑ Exercise

The pattern is: “Write a failing test that reproduces the issue, then fix it” — make Claude first encode the bug as a test that fails, then make that test pass. It outperforms “fix the login bug” for two reasons. First, the failing test is an unambiguous success criterion: Claude can iterate against ground truth on its own turns instead of waiting for you to judge each attempt — the highest-leverage move in the loop. Second, the test persists as a regression contract: it stays green afterward, so the same bug cannot silently return. “Fix the login bug” gives Claude no way to check itself and leaves nothing behind to prove the fix held.

Exam essentials

Four-phase rhythm — Explore (read-only / plan mode) → Plan → Implement (verify against plan) → Commit; skip the plan only when the diff is one-sentence-describable.
Interview pattern — for large features, Claude interviews you via AskUserQuestion, writes a SPEC.md, and a fresh session implements from it (clean context).
Verification is the single highest-leverage move — include tests, screenshots, or expected outputs so Claude checks itself; without criteria, the human is the only feedback loop.
Concrete beats vague — replace “the build is failing” with the error plus “address the root cause”; the delta is verb + concrete example/test/file + a verification step.
Course-correct early, then restart — tight loops beat drift, but after two corrections on the same issue, /clear and rewrite the prompt incorporating what you learned.