# Claude Code Plan Mode and Verification Workflow

> A step-by-step Claude Code workflow: explore in plan mode, write a spec, give the agent a check it can run, then review in a fresh context before you commit.

17 October 2026 · Technical · How-to · 7 min read · https://bridge-terminal.com/atlas/blog/claude-code-plan-mode-verify-workflow/

## The short version

- Use plan mode when a change touches several files, the approach is uncertain or the code is unfamiliar; skip it when you could describe the diff in one sentence.
- Give Claude Code a check it can run, such as tests, a build or a linter, so it iterates until the check passes instead of stopping when the work merely looks done.
- For larger features, have Claude interview you, write a spec to a file, and implement it in a fresh session with clean context.
- Make the check stricter as the run gets less supervised: a prompt, then a /goal condition, then a Stop hook that blocks the turn until the check passes, or a verification subagent for a second opinion.
- Have a second session or subagent review the diff in fresh context, and tell it to flag only gaps that affect correctness or the stated requirements.

A reliable way to get good results from Claude Code is a loop of four steps: explore and plan without editing, implement against a written plan, give the agent a check it can run, and review the result in a fresh context. This article walks through that plan mode workflow with the keys, flags and prompts to use, based on Anthropic's best-practices guidance for Claude Code.

Most of the advice rests on one constraint: Claude's context window fills up fast, and performance degrades as it fills. Every message, every file Claude reads and every command output sits in that window. Good workflows keep it clean and give the agent a way to know when it is finished.

## Why does Claude Code need a workflow at all?

Claude stops when the work looks done. The docs put it plainly: without a check it can run, "looks done" is the only signal available, and you become the verification loop. Every mistake waits for you to notice it.

Two habits fix most of this:

- Separate research and planning from implementation, so the agent does not solve the wrong problem.
- Attach a pass/fail check to every task, so the agent can find its own mistakes.

The workflow below assumes your build and test commands are written down in your project's CLAUDE.md file, which Claude reads at the start of every conversation.

## How do I use plan mode in Claude Code?

In plan mode Claude reads files and answers questions without making changes. Claude Code blocks edits until you approve a plan. There are two ways in:

```bash
# start a session in plan mode
claude --permission-mode plan
```

Or, inside a running session, press `Shift+Tab` until the status bar shows `⏸ plan mode on`.

The recommended flow has four phases.

### 1. Explore

Ask for understanding, not changes:

```text
read /src/auth and understand how we handle sessions and login.
also look at how we manage environment variables for secrets.
```

If the research is large, tell Claude to use subagents. A subagent runs in its own context window and reports back a summary, which keeps your main conversation free for the real work.

### 2. Plan

```text
I want to add Google OAuth. What files need to change?
What's the session flow? Create a plan.
```

Press `Ctrl+G` to open the plan in your text editor and edit it directly before Claude proceeds. This is the cheapest place to catch a wrong approach: a deleted line in a plan costs nothing, while a wrong assumption spread across ten files costs a revert.

### 3. Implement

Approve the plan, or press `Shift+Tab` to leave plan mode, and tell Claude to verify against it:

```text
implement the OAuth flow from your plan. write tests for the
callback handler, run the test suite and fix any failures.
```

### 4. Commit

```text
commit with a descriptive message and open a PR
```

### When should I skip plan mode?

Plan mode adds overhead. For tasks where the scope is clear and the fix is small, such as a typo, a log line or a rename, ask Claude to do it directly. Planning pays off when you are unsure of the approach, when the change modifies several files, or when you do not know the code well. The docs give a rule of thumb: if you could describe the diff in one sentence, skip the plan.

## How do I give Claude Code a way to verify its work?

The docs call this the difference between a session you watch and one you walk away from. Give the agent something that produces a pass or fail: a test suite, a build exit code, a linter, a script that diffs output against a fixture, or a browser screenshot compared with a design.

The difference in prompts is concrete:

| Vague | With a check |
| - | - |
| "implement a function that validates email addresses" | "write a validateEmail function. example test cases: user@example.com is true, invalid is false, user@.com is false. run the tests after implementing" |
| "the build is failing" | "the build fails with this error: [paste error]. fix it and verify the build succeeds. address the root cause, don't suppress the error" |
| "fix the login bug" | "users report that login fails after session timeout. check the auth flow in src/auth/, especially token refresh. write a failing test that reproduces the issue, then fix it" |

Note the last row: writing a failing test first gives the agent a target and leaves you with a regression test afterwards.

Ask for evidence rather than assertions: the test output, the command that ran and what it returned, or a screenshot. Reviewing evidence is faster than re-running the verification yourself, and it works for sessions you were not watching. After Claude's check passes, you can also run `/verify` yourself to confirm the change against the running app.

### How strictly should the check gate the work?

The docs describe four levels. Pick one by how much supervision the run will have.

1. **In one prompt.** Ask Claude to run the check and iterate in the same message. This works on any task today.
2. **Across a session.** Set the check as a `/goal` condition. A separate evaluator re-checks it after every turn and Claude keeps working until the goal resolves. If Claude stalls, Claude Code eventually stops the run with the goal still set.
3. **As a deterministic gate.** A Stop hook runs your check as a script and blocks the turn from ending until it passes. The hooks reference describes the cap on consecutive blocks.
4. **By a second opinion.** A verification subagent, or a dynamic workflow that checks its own findings, has a fresh model try to refute the result, so the agent doing the work is not the one grading it.

Each step trades setup effort for less of your attention. The docs say the `/goal` and Stop hook versions are what let an unattended run finish correctly without you.

## How do I write a spec for a bigger feature?

For larger features, let Claude interview you. Start with a minimal prompt and ask it to use the `AskUserQuestion` tool, replacing the bracketed text with your feature:

```text
I want to build [brief description]. Interview me in detail using the AskUserQuestion tool.

Ask about technical implementation, UI/UX, edge cases, concerns, and tradeoffs. Don't ask obvious questions, dig into the hard parts I might not have considered.

Keep interviewing until we've covered everything, then write a complete spec to SPEC.md.
```

Then start a fresh session to execute the spec. The new session has clean context focused on implementation, and you have a written document to point at. The docs say the most useful specs are self-contained: they name the files and interfaces involved, state what is out of scope, and end with an end-to-end verification step that proves the feature works. Time spent making the spec precise pays off more than time spent watching the implementation.

## How do I review the result?

Use a different context from the one that wrote the code. A reviewer in a fresh subagent sees only the diff and the criteria you give it, not the reasoning that produced the change, so it judges the result on its own terms.

The bundled `/code-review` skill reviews the current diff for bugs in a fresh subagent and returns the findings to your session. To check against your plan instead, write the prompt yourself. Name the work, the plan to check it against and what counts as a finding:

```text
Use a subagent to review the rate limiter diff against PLAN.md. Check that
every requirement is implemented, the listed edge cases have tests, and
nothing outside the task's scope changed. Report gaps, not style preferences.
```

One caution from the docs: a reviewer asked to find gaps will usually report some, even when the work is sound, because that is what it was asked to do. Chasing every finding leads to over-engineering, such as extra abstraction layers, defensive code and tests for cases that cannot happen. Tell the reviewer to flag only gaps that affect correctness or the stated requirements, and treat the rest as optional.

You can also use a Writer/Reviewer split across two sessions, or have one Claude write tests and another write code to pass them.

## What goes wrong, and how do I recover?

Correct course early. These controls are built in:

- `Esc` stops Claude mid-action and keeps context so you can redirect.
- `Esc` twice, or `/rewind`, opens the rewind menu, where you can restore the conversation, the code, or both, or summarize from a selected message.
- `/clear` resets context between unrelated tasks.

Checkpoints only track changes made through Claude's file-editing tools. Changes made through Bash commands or other processes are not captured, so checkpoints are not a replacement for git.

The failure patterns the docs name are worth remembering:

- **The kitchen sink session:** unrelated tasks in one context. Fix: `/clear` between them.
- **Correcting over and over:** after two failed corrections, `/clear` and write a better first prompt using what you learned.
- **The trust-then-verify gap:** a plausible implementation that misses edge cases. Fix: always provide tests, scripts or screenshots. If you cannot verify it, do not ship it.
- **The infinite exploration:** an unscoped "investigate". Fix: scope it narrowly or use subagents.

## How does this map to a team process?

The same ideas scale from one terminal to a team: nothing is built until the approach is agreed, nothing is done until a check passes, and someone other than the author reviews. Atlas, which runs a team of AI engineers on Claude Code, applies this order with gates: building waits for an approved architecture, a signed-off design and failing tests, and completion is refused until the work is on main or queued for the landing train and the product's rules pass. Every build is also reviewed as it finishes. Atlas does this with its own board and gates; it does not wrap the plan mode, `/goal` or Stop hook features described above. If you work alone in the CLI, plan mode, a failing test first and a fresh-context review give you a similar discipline. See the [Atlas home page](https://bridge-terminal.com/atlas/) for how the team version works.

## Conclusion

Plan when the change is big or unfamiliar; skip planning when the diff fits in a sentence. Write the spec to a file, run the work in a clean session, and do not accept "done" without a check the agent ran and showed you. Start small: add one runnable check to your next prompt, and move to `/goal` or a Stop hook once you trust the check enough to walk away.

## Questions people ask

### How do I turn on plan mode in Claude Code?

Press Shift+Tab until the status bar shows plan mode on, or start the session with claude --permission-mode plan. In plan mode Claude reads files and answers questions, and Claude Code blocks edits until you approve a plan.

### When should I not use plan mode?

Skip it when the scope is clear and the change is small, such as a typo, a log line or a rename. The docs suggest that if you could describe the diff in one sentence, skip the plan and ask Claude to do it directly.

### How do I make Claude Code check its own work?

Give it a check it can run, such as a test suite, build, linter or screenshot comparison, and ask it to run the check and iterate until it passes. For unattended runs you can set a /goal condition or use a Stop hook that blocks the turn until the check passes.

### Should the same session write and review the code?

Better not. A reviewer in a fresh subagent or session sees only the diff and your criteria, so it is not biased by the reasoning that produced the change. Tell it to flag only gaps that affect correctness or the stated requirements.

## About Atlas: Plan, test and review as enforced steps

This workflow is plan first, a check that must pass, then review by someone else. Atlas builds that order into its team of AI engineers: building waits for an approved architecture, a signed-off design and failing tests, and every build is reviewed as it finishes. Completion is refused until the work is on main or queued for the landing train and the product's rules pass. — https://bridge-terminal.com/atlas/

## Sources

- [Best practices for Claude Code](https://code.claude.com/docs/en/best-practices)
- [Choose a permission mode (Claude Code docs)](https://code.claude.com/docs/en/permission-modes)

_Researched and drafted with Claude, then checked against the sources above. Atlas is an independent product, not affiliated with Anthropic or OpenAI._