Claude Code /simplify and /batch

Problem: You wrapped up a feature in Claude Code. The tests pass. You also know a couple of functions repeat each other, a helper got reinvented, and there is at least one loop doing more work than it has to. Going back to fix all of it by hand means rereading every file you touched, spotting the rough edges yourself, and patching them one at a time. Ship as-is and tech debt eats you next sprint. Neither option feels good.

Quick Win: Right after a feature lands, type /simplify. It launches three review agents at once. One watches for code reuse. One watches for quality. One watches for efficiency. They pool their notes, apply the fixes, and hand you back a clean diff. No prompt to write. Just the command.

# After implementing a feature
/simplify
 
# Focus on a specific concern
/simplify focus on memory efficiency

New to Claude Code? The getting started guide covers the basics. Got something bigger on your plate, like moving a whole codebase from one framework to another or rolling a change across dozens of files? That is what /batch is for. Both commands landed in Claude Code v2.1.63, and between them they cover two workflows that used to need careful multi-step prompting.

What Claude Code /simplify Does

/simplify is a post-implementation cleanup command. Once the code works, /simplify rereads the diff and makes it better.

The first step is a call to git diff (or git diff HEAD) to see what moved. No git changes? It falls back to whichever files were touched most recently. From there, three review agents go wide in parallel. Each one sees the full diff:

The three run side by side. Once they finish, /simplify folds their notes together, patches every real issue directly, and quietly drops anything that looks like a false positive. You get a short summary of the fixes, or a note confirming the code was already in shape.

Boris Cherny, Claude Code's PM, framed it well: these bundled commands "automate much of the work it used to take to shepherd a pull request to production." /simplify is the automated review pass between "it works" and "it is ready to merge."

When to Use /simplify

The sweet spot is right after implementation, before you open a PR:

• After finishing a feature -- clean up before review
• After a bug fix -- make sure the fix didn't introduce shortcuts
• After a prototype -- tighten up experimental code you want to keep
• Before a PR -- catch issues a reviewer would flag

Want to narrow the focus? You can pass optional text:

/simplify focus on error handling
/simplify check for unnecessary dependencies
/simplify look at the database query patterns

That is handy when you know one area is rough but do not feel like writing a full prompt to describe the codebase. The command already knows which files moved.

What /simplify Is Not

/simplify is not a linter. Not a formatter either. It works at a higher level than that, looking at architecture calls, code structure, and algorithm choices. ESLint and Biome stay in the loop. /simplify handles the concerns those tools cannot catch. For validation-style enforcement, hooks already exist.

It is also not a blanket refactoring tool. Its attention stays on whatever changed recently, not the entire project. For a codebase-wide change, you want /batch.

What Claude Code /batch Does

Claude Code's /batch command coordinates large changes across your project, in parallel. The user-facing interface is deliberately plain. Nothing but a description and a few usage examples:

/batch migrate from react to vue
/batch replace all uses of lodash with native equivalents
/batch add type annotations to all untyped function parameters

You say what has to change. /batch hands it to a deeper orchestration agent that does the research, the decomposition, the execution, and the PR creation. Under the hood, the orchestrator runs a three-phase loop.

Phase 1 -- Research and Plan. The orchestrator drops into plan mode. It spawns Explore agents to trace every file, pattern, and call site that the instruction touches. From that, it breaks the work into 5 to 30 self-contained units, sized against the codebase and the change. Every unit has to be implementable on its own inside a worktree, and mergeable on its own without waiting on another unit to land first. The orchestrator also works out a verification recipe end to end, whether that is browser automation, a CLI test, or your existing test suite. If it cannot figure out how to verify the work, it stops and asks you.

Phase 2 -- Spawn Workers. Once you approve the plan, the orchestrator fires off one background agent per unit. All of them go out in a single message block, so the parallelism is real. Each agent runs with isolation: "worktree" for a clean git worktree. Each agent's prompt is self-contained: the overall goal, the specific task, and the codebase conventions picked up during research. It also carries the end-to-end test recipe and the worker instructions. After writing the code, each worker runs /simplify on its own diff, runs the test suite, commits, pushes, and opens a PR with gh pr create.

Phase 3 -- Track Progress. The orchestrator renders a status table and keeps updating it as agents finish, pulling PR URLs out of each worker's output. At the end you get a summary line like "22/24 units landed as PRs."

Worktree isolation is the piece that makes any of this work. Every agent has its own branch and its own working copy, which means no agent can step on another. Merge conflicts never appear. Each unit stays independently testable and reviewable.

# Large-scale migration
/batch migrate src/ from Solid to React
 
# Pattern application
/batch add input validation to all API endpoints
 
# Convention enforcement
/batch rename all database columns from camelCase to snake_case
 
# Dependency update
/batch update all axios calls to use the new fetch wrapper

The Plan Step

Before a single file changes, /batch lays the plan out. You see every unit of work, which files it plans to touch, and what the change involves. Nothing runs until you approve it.

That is what makes /batch predictable. You are not handing your project to an autonomous process and crossing your fingers. The decomposition is visible. You verify it makes sense. Then you let it loose.

If the plan is off (maybe it missed some files, maybe it grouped things badly), you tell it to adjust before execution starts. This is the same spirit as planning modes for individual tasks, only scaled out to the whole repo.

Requirements

/batch needs a git repository. No exceptions. Every agent unit runs inside its own git worktree, and each one opens a pull request at the end. Outside a git repo, /batch refuses to start.

The worktree rule is also what keeps your changes safe. Each agent's work sits on its own branch. If one unit flops or puts out bad code, the others keep going. Good PRs get merged. Bad ones get tossed.

When to Use /batch

/batch is meant for work that parallelizes cleanly. That is, dozens or hundreds of files all need the same kind of edit, and no single edit depends on another.

Good fits:

• Framework migrations -- converting components from one framework to another
• API contract changes -- updating all callers when an interface changes
• Convention enforcement -- applying naming conventions, adding error handling, or standardizing patterns across the codebase
• Dependency swaps -- replacing one library with another across all usage sites
• Test generation -- adding test coverage to untested modules

Bad fits:

• Tightly coupled changes where file A depends on file B's new output (these aren't independent units)
• Exploratory refactoring where you don't know the end state yet
• Single-file changes that don't warrant decomposition

If the work needs agents coordinating with each other, say agent A creates a shared utility and agent B has to import it, /batch is the wrong tool. Regular Claude Code sessions or agent teams handle that kind of cross-talk.

/simplify vs /batch: When to Use Each Command

The two commands solve different problems at different scales. Decision framework:

A useful mental picture: in Claude Code, /simplify is your code reviewer. /batch is your migration team.

They also pair up by design. Every /batch worker runs /simplify on its own changes before committing. So every PR that comes out of /batch has already been through the three-agent pass. No manual chaining. The integration is already wired in.

Practical Workflow Examples

Example 1: Feature Development Cycle

You just wired up a new authentication flow across 4 files:

# 1. Implement the feature (normal Claude Code session)
"Add JWT authentication with refresh tokens to the API"
 
# 2. Clean up with /simplify
/simplify
 
# 3. Focus on specific concerns if needed
/simplify focus on security patterns in the auth flow

The three review agents comb the auth code for duplicated token validation logic, for quality issues like inconsistent error responses, and for efficiency problems like unnecessary token decoding.

Example 2: Framework Migration

Your frontend has 45 React class components that need to become functional components with hooks:

# 1. Describe the migration
/batch convert all React class components in src/components/ to functional components with hooks
 
# 2. Review the plan (batch shows 15 units of ~3 components each)
# 3. Approve
# 4. Each agent creates a PR with its batch of conversions
# 5. Review and merge PRs individually

Every PR stands on its own for review and merge. If one conversion turns tricky and needs a human touch, that PR goes aside while the rest keep moving.

Example 3: API Standardization

Your API endpoints use inconsistent error response formats:

/batch standardize all API error responses to use { error: string, code: number, details?: object } format

/batch finds every endpoint, bundles them into independent units (usually by route file or domain), and turns each agent loose on its assigned routes. Every unit runs the existing test suite after the edits, so you learn fast if anything broke.

Bundled Commands vs Custom Slash Commands

/simplify and /batch are bundled Claude Code commands. They ship with every install and work out of the box. Custom slash commands are the other flavor: project-specific prompts you write yourself, either in your CLAUDE.md configuration or under .claude/commands/, much like the skills you define for your own workflow. Bundled commands are maintained by Anthropic and ship updates with each Claude Code release.

The difference matters because bundled commands reach into internal capabilities that custom commands cannot. /batch can spawn agents in isolated worktrees and open PRs automatically. /simplify can fire off its three-agent review pipeline without you writing a single line of orchestration glue.

That said, the two sides complement each other. Custom commands own the project-specific stuff (your deploy process, your testing conventions, your code generation patterns). Bundled commands own the universal stuff (code review, codebase-wide edits) that applies to any project.

Built your own sub-agent workflows that hand-roll a multi-agent review pass? /simplify might replace them outright. Been writing scripts to apply repetitive edits across files? /batch is the Claude-native version of that script.

Tips for Using /simplify and /batch Effectively

Run /simplify before every PR. Make it a habit. The three-agent pass catches things you will miss after hours of heads-down implementation work. In practice, /simplify reliably turns up 3 to 5 issues per feature branch that would otherwise surface during code review. The efficiency agent in particular is strong at catching wasted iterations and missed concurrency opportunities.

Be specific with /batch descriptions. "Update the codebase" is too vague. "Replace all moment.js imports with dayjs, updating the API calls to match dayjs's syntax" gives the planner enough context to decompose the work properly.

Check the /batch plan carefully. The decomposition step is where most issues show up. If a unit covers too many files or mixes independent changes, ask for a different split before approving.

Use /simplify's optional focus text. When you know an area is rough, maybe because you took a shortcut during prototyping, point /simplify right at it. A targeted review gets better results than a generic sweep.

Combine /batch with your test suite. Every /batch agent runs tests after editing. Make sure those tests actually catch regressions. Weak tests mean /batch agents will "pass" broken code.

FAQ

Does /simplify modify files automatically?

Yes. /simplify writes fixes straight into your working copy. Review them with git diff before committing. Wrong fix? git checkout the file to revert it.

What happens if a /batch worker fails?

A failed worker does not take the others with it. Each runs in its own git worktree, on its own branch. The failure shows up in the status table, and you either retry that unit or take it by hand. PRs that already landed are untouched.

Which version of Claude Code ships these commands?

/simplify and /batch shipped in Claude Code v2.1.63. Run claude --version to check. On an older build, claude update pulls them in.

Can /batch handle monorepos?

Yes. /batch works in any git repository. Inside a monorepo, be specific about which packages or directories to target in your description so the planner decomposes the work correctly.

How is /simplify different from a linter?

Linters catch syntax and style issues. /simplify catches architectural problems: duplicated logic, missed abstractions, performance inefficiencies, and patterns a human reviewer would flag. They cover different layers.

Next Steps

• Read about git worktrees in Claude Code to understand the isolation model /batch uses
• See how /simplify and /batch slot into the full interactive mode slash command system, including session controls, keyboard shortcuts, and /btw side questions
• Learn how agent teams work for coordinated multi-agent tasks that /batch cannot handle
• Explore custom slash commands to build project-specific workflows alongside these bundled ones
• Check sub-agent best practices for designing your own multi-agent patterns
• Review the feedback loops guide for building review cycles into your development process
• See the full v2.1.63 changelog for everything else that shipped with these commands
• Need to install or update Claude Code? The installation guide covers setup on every platform, including the one-line install commands

/simplify and /batch show where Claude Code is heading: bundled multi-agent workflows that handle common engineering patterns out of the box. You still review every diff. You still approve every plan. But the orchestration work, the parallel agent spawning, the worktree management, the result aggregation, is no longer something you wire up yourself. Expect more bundled commands along these lines as the platform matures.

Want a development framework with pre-built agent orchestration, custom slash commands, and multi-agent patterns that sit alongside these bundled commands? The ClaudeFast Code Kit ships with 18 specialized agents and a pipeline designed for exactly this kind of workflow.