Explore, plan, code, verify: the loop that works

Most disappointing sessions fail in one of two ways: Claude builds something other than what you meant, or it says "done" when it is not. This guide gives you a four-part loop that fixes both. It is for anyone past their first few sessions who wants changes they can trust. At the end you will run a real feature through explore, plan, code and verify, with proof at every step.

What you will have at the end

A habit of letting Claude read before it writes
A reviewed plan, or a written SPEC.md, before any edit happens
A pass or fail check that Claude runs on its own work
Evidence you can read in seconds instead of rerunning tests yourself
Three controls to steer a session that drifts

Before you start

Claude Code installed and signed in. See Start here.
A project with at least one command that comes back pass or fail: a test suite, a typecheck, a build or a linter.
Ideally a CLAUDE.md that lists that command. See Write a CLAUDE.md that actually helps.

Step 1: Explore before you touch anything

Start with questions, not instructions:

give me an overview of this codebase

Then narrow down to the area you are about to change, for example how is authentication handled?. These prompts come from the common workflows page, which suggests going from broad to specific.

If the area is large, push the reading into a subagent so only the findings come back to your conversation:

use a subagent to investigate how our auth system handles token refresh

The subagent reads files in its own context window and reports a summary (common workflows).

Step 2: Plan with plan mode

Plan mode lets Claude research and propose changes without editing your source (permission modes). There are three ways in:

Press Shift+Tab until the status bar shows ⏸ plan mode on.
Start one prompt with /plan, for example /plan fix the auth bug (commands).
Launch the whole session in plan mode:

claude --permission-mode plan

When the plan is ready, Claude asks how to proceed. You can approve and let it continue in auto mode, approve and review each edit yourself, or say "No, keep planning" and tell it what to change. Press Ctrl+G to open the plan in your text editor and edit it directly before Claude starts (review a plan).

Read the plan the way you would read a colleague's. Does it touch the files you expected? Does it say how it will test the change? Push back now. Fixing a plan costs a sentence, while fixing code costs a rewrite.

Step 3: Interview to a spec for bigger work

When you do not yet know exactly what you want, let Claude ask the questions. This prompt is from the best practices page:

I want to add rate limiting to the public API but haven't thought it through yet. Interview me until you could write the spec, then write it to SPEC.md.

Claude comes back with multiple-choice questions on the parts you have not pinned down, such as per-user versus per-key limits, and keeps going until the answers add up to a spec.

When SPEC.md is written, open a new session for the build. Claude then starts with nothing but the spec, which doubles as your checklist for review later.

Step 4: Code with a specific prompt

Now ask for the change. A specific prompt saves a round of corrections because it gives Claude information it cannot get from the code. Name the file, describe the symptom and say what "fixed" looks like. The best practices page gives this example instead of "fix the login bug":

users report login fails after the session times out. look at token refresh in src/auth/, write a failing test that reproduces it, then fix it

If you want the fuller version with edge cases and states handled, say "be ambitious". Claude otherwise tends to build the smallest thing that satisfies the request.

Step 5: Verify with a check Claude can run

This is the step people skip, and it is the one that matters most. The best practices page puts it plainly: "Claude stops when the work looks done." Without something to run, looking done is all it has.

Give it a check that comes back pass or fail: a test file, a build exit code, a linter, a script that diffs output against a fixture, or a browser screenshot next to the mockup (give Claude a check). Then pick how strict to be:

In the prompt: run the auth tests after, and keep going until they pass. No setup needed.
As a goal: /goal all tests in tests/auth pass and lint is clean. A separate model checks the condition after every turn (goal). This matters most for long runs.
As a Stop hook: a script runs whenever Claude tries to finish and sends it back to work if the script exits with code 2.
By a fresh reviewer: /code-review reviews the diff in a subagent that never saw your conversation.

Whichever you choose, ask for evidence: the command Claude ran and its output. "All tests pass" alone tells you little. When Claude says it is done, you can also run /verify, which has Claude build and run the app and look at the result (best practices).

To review against your plan instead of hunting for bugs in general, point a reviewer at the spec:

use a subagent to review the rate limiter diff against SPEC.md, check every requirement is implemented and the listed edge cases have tests, report gaps that affect correctness and skip style

Keep the "skip style" part. A reviewer asked to find problems will always find something.

Step 6: Steer when it drifts

Watch the first minute of any task. Three controls cover nearly every correction (steer the session):

Esc stops Claude mid-action and keeps the work so far.
/rewind, or Esc twice on an empty prompt, rolls code, conversation or both back to an earlier prompt. Checkpoints cover edits made with Claude's file tools, not changes made only by Bash commands, so keep using git.
/clear starts over. After two failed corrections, clear and write one better prompt.

Check it worked

Run one small feature through the loop and confirm:

The plan Claude showed in step 2 matches the files in git diff --stat.
Claude's final message includes the check command and its real output, not only a summary.
Running the same check yourself gives the same pass result.

Common problems

Claude edits during planning. You are not in plan mode. Look for ⏸ plan mode on in the status bar before you send the prompt, or start the prompt with /plan.

Plan mode keeps asking to run commands. When auto mode is not available, commands outside the built-in read-only set prompt for approval during planning (plan mode). Approve the safe ones or add allow rules.

Claude says done but the feature is broken. It had nothing to run. Add the test or typecheck command to CLAUDE.md and ask for the output as evidence.

The review buries you in nits. Tell the reviewer to report only issues that affect correctness and to skip style, as in the prompt in step 5.

Pick the right model and effort for each task: when to raise effort for the verify step.
Code review that catches real bugs: the paid guide with a REVIEW.md and reviewer agents.

Sources

Last checked: 2026-11-06