Daily workflows |

The explore → plan → code → commit workflow

Sat, 03 Oct 2026 00:00:00 +0000

To be effective with Claude Code, follow the Explore, Plan, Code, and Commit workflow:

Explore gives Claude the relevant context it needs for your project.
Plan creates a plan of action that Claude uses to measure success.
Code is the back and forth between you and Claude before settling on the final outcome.
Commit helps you review and push your code so you can start on your next feature.

Explore and Plan

The fastest way to handle these first two steps is with Plan Mode.

In plan mode, Claude can’t edit files — it just reads files to gather information about how it will tackle the implementation.
Claude will read relevant files, run some web searches, and give you a plan of action. Review it and decide if it meets your criteria. If not, ask it to revise specific areas.

This is the best place to course-correct because it’s before any code is written.

You can also run the explore subagent without being in plan mode if you just want a general summary of your codebase without intending to make changes afterward.

Code

Once the plan looks good, select “approve” to accept it and let Claude work through the list items. Your permission mode determines how Claude proceeds: it can ask you at each step, auto-accept file edits, or run in auto mode with a background safety check screening each action.

Claude will do its best to troubleshoot before considering the plan “finished,” but at times you’ll need to step in.

Tip

Tips to make the coding phase smoother:

Define a success criteria.

For Claude to be confident in its results, it needs to be clear on what “correct” looks like. Make this explicit when writing your plan.
Add tools.

Tools that help Claude complete its goals remove a lot of back and forth. For example, if you’re building web UIs, install the Claude in Chrome extension so Claude Code can control a browser tab and test the UI directly.
Include a test suite.

Give Claude a test suite it can continuously validate against. Claude can even write tests for you. Before handing this off, make sure the tests are a reliable source of truth to avoid false positives.

Tip

If you find Claude keeps running into the same issues, ask it to save the solution to its CLAUDE.md file.

Commit

Once you’ve tested the changes yourself and are happy with the results, it’s time to push your code.

Before you commit, run a subagent code reviewer to look at your work. A subagent gets a fresh pair of eyes on the codebase — it doesn’t carry the bias the main agent might have from the session.

Then get Claude to generate a commit message in your style.

Context management

Sat, 03 Oct 2026 00:00:00 +0000

What is the Context Window?

Context window = the amount of space Claude can hold in its memory

E.g.: Whenever you enter a prompt, Claude reads a file, runs a tool call, or receives a tool call result, it’s all adding to the context window.

What Happens When Context Fills Up

When you approach the limit, the context window is automatically compacted.

Compaction summarizes important details and removes unnecessary tool call results to free up space.
Note that this process can potentially lose details.

Commands

Command	What it does	When to use
`/context`	Check the state of your context	When you want to get a high-level overview of your context size, the categories taking up the most space, and a visual graphic showing the breakdown.
`/compact`	Compacts everything up to that point.	When you want to free up context space while keeping a memory of what you previously worked on. Example: when you’re working on a specific feature and running up against the context limit but need to continue.
`/clear`	Removes everything	If you want to completely start from scratch with no memory of the previous session. For things you want Claude to remember across sessions, put them in your CLAUDE.md file so it doesn’t have to rediscover things from scratch. Example: when you want to start a new feature. You don’t want the previous conversation to introduce bias into something new.

Tips for Saving Context Space

Be specific.

A vague prompt might seem smaller, but it actually costs more context in the long run. Without clear instructions, Claude is forced to explore your codebase more and do its own reasoning — which takes up far more context space than a detailed prompt would.

Manage your MCP servers.

MCP servers load all of their available tools into context by default, even when you’re not using them. If you have servers configured for things unrelated to the current project, consider turning them off. You can also try “Skills,” which work similarly to MCP servers but don’t load everything into context upfront.

Use subagents.

Subagents run in parallel with your main agent but have a completely separate context window. For tasks where you only need the answer — like “where are the authentication endpoints located?” — a subagent does the work and returns just a summary to your main agent, keeping your primary context clean.

Code review

Sat, 03 Oct 2026 00:00:00 +0000

TL;DR

Read the actual diff of the file changes before you trust the summary alone. Run /diff and look for changes you didn’t ask for, weaker tests, and new packages or hard-coded values.
Get a second opinion from a clean context with /code-review (or ask in plain words and let Claude start it).
Treat each finding as
- fix now,
- ask why, or
- leave it
, and ask for evidence with every fix.

It's a good practice to give every change a look yourself before you keep it, and then have Claude review it again from a clean context, without this session's history.

When you give Claude Code a task to complete in your codebase, Claude will often report back in a succinct way. Underneath the description of what Claude changed, there can be a variety of files that were changed (from small to major changes). Oftentimes, the session that wrote the code changes themselves (and explained them) is not the highest-quality judge of those changes.

Review the Actual Changes

A diff is the before-and-after of a change: the lines removed and the lines added, file by file.

The /diff command opens an interactive viewer of your uncommitted changes in that form, and it can also show what each of Claude’s turns changed.

The most important things that deserve a second look every time are:

Changes you didn't ask for

A config value that was edited while Claude was in the file or a rewritten helper method that you didn’t mention.

Tests that got weaker

If the project you’re working in contains tests, identify any that were skipped, deleted, or loosened until they passed.

New packages and hard-coded values

A dependency that was added for only one function, a URL or a key written straight into the code.

If the whole change is wrong, run /rewind (or press Esc twice on an empty prompt), pick the prompt that produced it, and choose Restore code and conversation.

Caution

Files changed by shell commands Claude ran, such as a package install, aren’t rolled back.

Ask for a Second Opinion

A long session carries everything it has read and decided. That’s the context you learned to manage in the previous lesson, and it’s exactly the history you do NOT want in a reviewer.

/code-review is that second reviewer: it reviews the change in a clean context, with none of your session’s history, and reports what it finds. It edits nothing unless you ask it to.

The review runs in the background, anywhere from seconds to a few minutes, and counts against your usage like any other task, so save it for changes that deserve a second look. The findings arrive in your conversation when it finishes.
You can also ask in plain words, and Claude can start the same review from the request. For example:
```
Review the changes you just made. Report problems; don't fix anything yet.
```
If Claude answers inline instead of starting a review, run the command yourself.

Tip

Add an effort level to the command if you want a lighter or a deeper review.

/code-review low reports only the findings it’s most confident about, so you see fewer false alarms.
/code-review high casts a wider net and may include findings it’s less sure of. The level you type is remembered for later reviews until you type a different one.

Decide What to Do with Each Finding

Sort each finding into one of three piles:

Fix now.
- This is a real problem, it matters, and it must be fixed.
- Whenever you ask for a fix, it’s good to ask for evidence with it.
- If a fix eventually grows into a large change of its own, run the review again.
Ask why.
- This is the pile for findings you can’t quite verify or that seem off. It’s possible for reviewers that are reading code changes cold to also miss things.
- To ask why, quote the finding back to Claude and ask Claude to check again.
Leave it.
- This is a real problem but small or inconsequential. These can often be batched into a group of fixes that you’ll cover in one future session.

Tip

When the reviewer flags the same issue a few times, it might be a good idea to write a rule for Claude to read at the start of every session. That file is CLAUDE.md.

When it Pays off to Review Things More Closely

You should use a human review and a Claude review when

a change is bigger than you could hold in your head,
it touches something sensitive or does something destructive, and
before you hand the work to a teammate.