Claude Code, Part 2: Before You Commit
AI makes generation fast. Verification is where the bar now sits.
The Commit Gate
You've written code with Claude Code. Tests pass. Before you commit, run this sequence:
| # | Step | What it does |
|---|---|---|
| 1 | /diff | See every change Claude Code made |
| 2 | /simplify | Clean up redundancies and quality issues |
| 3 | /diff | Verify what /simplify changed |
| 4 | Review | Structured analysis for bugs and security |
1. /diff: See What Actually Changed
Opens an interactive diff viewer showing your uncommitted changes and per-turn diffs.
/diff
Two views:
- The current git diff: all uncommitted changes in your working tree
- One view per Claude Code turn: what changed in that turn alone
Use left/right arrows to switch between views and up/down to browse files. The per-turn views are the important ones: when Claude Code made 15 edits across 6 files, you can scrub turn by turn to find which one introduced an unexpected change.
When to use:
- After Claude Code makes a series of edits, before moving to the next phase
- Before committing, always, no exceptions
- When you lose track of what changed across multiple files
What to look for:
- Files you didn't expect to see (scope creep)
- Deleted code that wasn't discussed
- Formatting changes hiding logic changes
- New abstractions or wrappers you didn't ask for
The habit: /diff before every commit. It's your last chance to catch mistakes before they compound. Finding a problem now takes 30 seconds. Finding it after three more implementation steps takes 30 minutes.
What to Look for in Any Diff (Quick Checklist)
This is the minimum review. Do this every time.
When /diff is open, scan in this order. Takes 60 seconds for small changes, 5 minutes for large ones.
| # | Check | What you're catching |
|---|---|---|
| 1 | Plan match | Does the diff match what was approved? |
| 2 | File list | Are only planned files here? Any surprises? |
| 3 | Extras | Did Claude Code add wrappers, helpers, or abstractions you didn't ask for? |
| 4 | Failure paths | What happens when this code fails? Empty catches? Missing validation? |
| 5 | Imports | New dependencies? Unused imports? Wrong paths? |
| 6 | Tests | Do they exist? Do they test behavior, not implementation? Were existing tests modified to pass? |
If any check fails, fix before committing. If check 1 fails (wrong approach), go back to plan.
If you skip this, you're not reviewing. You're trusting.
2. /simplify: The Second Pass
Spawns four review agents in parallel against your recently changed files (covering reuse of existing helpers, simplification, efficiency, and whether the change sits at the right level of abstraction), aggregates their findings, then applies fixes. Pass a path or PR reference to scope it to a specific target: /simplify src/auth.
/simplify
Why this matters: AI-generated code often has subtle redundancies or missed optimization opportunities. A first pass writes working code. A second pass catches what the first pass missed: duplicate logic, unnecessary abstractions, inconsistent patterns.
When to use:
- After Claude Code writes a significant chunk of code
- Before creating a PR
- When the implementation "works but feels heavy"
When NOT to use:
- On tiny changes (single function, config update): overhead exceeds benefit
- When you need to understand every change before cleanup (review first, simplify second)
The habit: /diff → /simplify → /diff → review → commit. The simplify pass catches things you'd otherwise find in PR review.
3. Review: Structured Code Analysis
After verifying the diff looks clean, ask Claude Code to analyze the changes for logic errors, security issues, and missing error handling.
The simplest approach: ask Claude Code directly.
Review the changes you just made. Look for bugs, security
issues, and missing error handling. Use BLOCK/WARN/NOTE
severity levels.
If you want a built-in review command, Claude Code ships with several:
/review [PR]: Review a pull request locally in your current session./code-review ultra [PR]: Deeper, multi-agent review in a cloud sandbox (/ultrareviewis the older alias). Some plans include a limited number of free runs; beyond that it's billed as usage. Check the command in-session for current availability and pricing./security-review: Analyse pending changes on the current branch for security vulnerabilities (injection, auth issues, data exposure).
For community-built review plugins, browse the marketplace with /plugin.
When to use:
- Before creating a PR for important changes
- When changes touch security-sensitive code (auth, payments, user data)
- When you want a second opinion on your own implementation
The difference from /diff:
- /diff shows you WHAT changed (you review it yourself)
- A review prompt asks Claude Code to ANALYZE what changed (Claude Code reviews it)
Both are valuable. /diff catches scope creep and unexpected changes. Review catches logic errors and security issues. Use both.
The Pre-Commit Flow
This takes 2-5 minutes for most changes. It catches the majority of issues before they reach PR review, where they're far more expensive to fix.
The One Rule
The faster code was produced, the slower you should review it.
A feature Claude Code wrote in 90 seconds deserves the same scrutiny as one a junior engineer wrote in 3 hours. /diff → /simplify → /diff → review is how you apply that scrutiny systematically.
The comprehension test: If you can't explain what the code does and why, don't commit it. AI shifts mistakes from syntax errors to conceptual errors: code that works but that you don't understand. The moment you stop understanding what's in your repo, you stop engineering and start hoping.
This lesson is from the Claude Code Field Guide, a free companion to Claude and the Code. The book teaches the thinking behind the commands.
You've completed 2 of 6 lessons.
Want the complete methodology?
The Field Guide teaches commands. The book teaches thinking.