Claude Code workflow: a daily loop of explore, plan, code, test and commit

What does a good Claude Code workflow look like?

Claude Code can take one big prompt and run with it. That works for small jobs. For anything that touches several files, a fixed loop works better, because each step gives you a place to look at the result and say no before the next step builds on it. The loop below has five steps. Anthropic’s own pages describe the pieces, which this page links, but the five-step order is this page’s arrangement of them, not an official method.

Two controls sit outside the loop and matter every day: Esc to stop Claude mid-action, and /rewind to roll code and conversation back to an earlier prompt. The rest of this page walks through the setup, each step with prompts you can copy, and how to run more than one loop at a time.

What should you set up once before the loop?

The loop only works if Claude can check its own work. That means it needs to know your test, typecheck and lint commands. Put them in a CLAUDE.md file at the root of the repository. Claude Code loads that file at the start of every session, so you type the commands once instead of every morning.

Run /init to generate a starting version from your codebase, then cut it down. The memory guide recommends staying under 200 lines, and the best practices page says to write down only what Claude cannot work out by reading the code. Run /context afterward and look under Memory files to confirm the file loaded.

# Commands
- Install: pnpm install
- Run one test file: pnpm vitest run path/to/file.test.ts
- Run all tests: pnpm test
- Typecheck: pnpm tsc --noEmit
- Lint: pnpm lint

# Conventions
- Validate all request bodies with the zod schemas in src/schemas/
- src/legacy/ is still live, but do not copy its patterns into new code

# Gotchas
- Integration tests need DATABASE_URL set, see .env.example
- Never edit src/gen/, it is generated

Personal preferences go in CLAUDE.local.md, which you add to .gitignore. Rules that apply to one folder go in .claude/rules/ with a paths: filter so they load only when Claude works there. For a deeper look, see how to write a CLAUDE.md.

How do you start the day and pick up yesterday’s work?

Claude Code saves every conversation locally, so you do not re-explain context each morning. From the project folder:

• claude --continue resumes the most recent session in the current directory. If there is none, it prints No conversation found to continue and exits.
• claude --resume opens a list so you can pick a session. Inside a running session, /resume does the same.
• /rename oauth-migration names the current session. Later, claude --resume oauth-migration from your shell picks it back up, checkpoints included.
• claude --from-pr 1234 (with your own PR number) opens the session picker filtered to sessions linked to that pull request.

If yesterday’s conversation went sideways, do not resume it. Start fresh with claude and a better first prompt. The docs say a clean context with one well-aimed prompt usually beats a long conversation that already contains failed attempts.

Step 1: How do you explore the code before changing it?

Start with questions, not edits. The common workflows page suggests moving from broad to narrow: an overview first, then architecture, then the specific component you plan to change.

give me an overview of this codebase

explain the main architecture patterns used here

find the files that handle user authentication

trace the login process from the form to the database, and list every file involved

When the exploration would read a lot of files, hand it to a subagent so only the findings come back to your main conversation:

use a subagent to investigate how our auth system handles token refresh, and report the files, the functions, and anything that looks fragile

Claude Code includes a built-in read-only Explore subagent for this kind of search. Its Write and Edit tools are denied, so exploration cannot change your files.

If you do not yet know what you want, let Claude interview you. This prompt comes from the best practices page and ends in a written spec you can build from in a fresh session:

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.

The spec file is the handoff. Start a new session to build from it so the build begins with a clean context and a written definition of done.

Step 2: How do you plan a change in plan mode?

In plan mode, Claude reads files, can run shell commands to explore, and writes a plan, but does not edit your source. Edits stay blocked until you approve the plan. There are three ways in:

• Press Shift+Tab in a session until the status bar shows ⏸ plan mode on.
• Prefix one prompt with /plan, for example /plan fix the auth bug.
• Start the session in it with claude --permission-mode plan.

When the plan is ready, Claude asks how to proceed. The options are to approve and start in auto mode, to approve and review each edit by hand, or to keep planning and tell Claude what to change. Press Ctrl+G to open the plan in your text editor and edit it directly before approving.

/plan add a CSV export button to the invoices page. Read how the existing PDF export works first and follow its pattern. No new dependencies. List the files you will change, the tests you will add, and anything you are unsure about before you edit.

Read the plan for scope first. If it lists ten files for a one-button feature, say so and send it back with “No, keep planning”. Plans are cheap to change and diffs are not.

You do not need a plan for every task. A rule of thumb that holds up in practice: plan when the change spans several files, when you are unsure of the approach, or when the code is unfamiliar. Skip it for a one-line fix or a typo, where the plan would be longer than the diff.

Step 3: How do you let Claude write the code without losing control?

Once you approve the plan, Claude edits. Your control comes from the permission mode and from three keys. As of October 2026, the docs say new terminal and VS Code sessions start in auto mode on Claude Code v2.1.283 or later, where a separate classifier reviews risky actions instead of asking you each time. Permission modes lists the rest.

Three controls for when it drifts:

• `Esc` stops Claude mid-action and keeps everything up to that point, so you can redirect without losing work.
• `/rewind` (or Esc twice on an empty prompt) opens the rewind menu. You can restore code, conversation or both to an earlier prompt, or summarize part of the conversation. Checkpoints cover files Claude edited with its own file tools, not files changed only by a shell command, and they work alongside git rather than replacing it.
• `/clear` starts over. The docs advise that after two failed corrections, a third mostly adds to a conversation that already holds two failed attempts. Run /clear and write one prompt that folds in what you learned.

Watch the first minute of any run. That is when a wrong assumption is cheapest to catch.

Step 4: How do you make Claude check its own work?

Claude stops when the work looks done. If it has nothing to run that returns pass or fail, “looks done” is all it has, and you become the test suite. The best practices page puts it plainly: give Claude something it can run, and it can close the loop itself. The options run from loose to strict.

The Stop hook is a few lines in .claude/settings.json. Exit code 2 blocks the stop, and whatever the command writes to stderr goes back to Claude as the reason it cannot finish yet:

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          { "type": "command", "command": "pnpm tsc --noEmit 1>&2 || exit 2" }
        ]
      }
    ]
  }
}

If a hook blocks eight stops in a row with no tool call between them, Claude Code overrides the next block and ends the turn, so a broken check cannot loop forever. Whatever method you pick, ask for evidence: the command Claude ran and its output. “All tests pass” on its own tells you little.

run pnpm test and pnpm tsc --noEmit. Paste the last 15 lines of each command’s output. If anything fails, fix it and run both again. Do not change existing tests to make them pass.

After Claude says it is done, you can also run /verify, which has Claude build and run the app and look at the result. That catches problems tests and typechecks miss. For an independent read of the diff, a review prompt like “use a subagent to review the rate limiter diff against SPEC.md, report gaps that affect correctness and skip style” works well. Keep the “skip style” part: a reviewer asked to find problems will always find something.

Step 5: How do you commit and open a pull request?

Claude can stage changes, write the commit message and open the pull request. Ask in plain words:

summarize the changes I've made to the invoices module

commit my changes with a descriptive message

create a pr for this feature

enhance the PR description with more context about the testing

Before you accept, read the changes yourself. /diff shows your working tree, including the edits Claude has made. The docs recommend reviewing the generated pull request and asking Claude to highlight risks before you submit. When Claude opens a PR with gh pr create, Claude Code links the session to that PR, so claude --from-pr 1234 finds it later.

Small commits help every other step. A clean commit is a clean place to /rewind to, and a small diff is a diff you can review. If the task grew, ask Claude to split the work into separate commits with separate messages.

What should you do between tasks?

• Run `/clear` between unrelated tasks. The docs note that most current models have a large context window and compact on their own, so running out is rare, but a focused context still gives better answers and costs less.
• Use `/compact` when you are mid-task and want room. It summarizes the conversation so far; you can pass focus instructions.
• Use `/btw` for a side question. It answers without adding anything to the history.
• Add to CLAUDE.md when you correct the same thing twice. The memory page lists that as the signal that a fact belongs in the file.

How do you run more than one loop at a time?

Give each task its own checkout so edits cannot collide. claude --worktree feature-auth (or claude -w feature-auth) starts a session in a new git worktree. Run it again with another name in a second terminal for a second isolated session. The repository needs at least one commit first.

A worktree is a fresh checkout, so gitignored files such as .env are missing. List the ones you need in a .worktreeinclude file at the repo root and Claude Code copies them into each worktree it creates. Keep that list to small files. For details, see Claude Code worktrees.

A second session is also the easiest independent reviewer. One session writes the change; another reads it without having watched it being written, and you paste the findings back.

What does one loop look like with real prompts?

Say the task is a small utility from the board: Explain this cron expression in plain English, and the reverse, posted on the board in the developer tools category. Here is the loop as seven messages, with the step each one belongs to.

Seven messages, five of them short. Looking for the next thing to build with this loop? Browse developer tool ideas on the board; every idea has a generated build prompt you can paste in as the first message.

What breaks a Claude Code workflow?

• No check to run. Without a pass-or-fail command, Claude’s “done” is a guess.
• A CLAUDE.md that keeps growing. Every line takes attention on every task. Cut what Claude can read from the code, and move hard rules into hooks.
• Correcting a third time. After two failed corrections, /clear and rewrite the prompt.
• Skipping the diff. Claude summarizes what it meant to do. Read what it did.
• Planning everything. A plan for a typo costs more than the typo.
• Overusing emphasis. The docs say piling on IMPORTANT or ALL CAPS mostly makes Claude over-apply the rule. If a rule cannot bend, make it a hook or a deny rule.

For the wider set of habits, read the Claude Code best practices and the Claude Code tutorial.