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. 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.
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. Use the up and down arrows to move between files and Enter to open one.
/diff
The most important things that deserve a second look every time are:
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. One limit worth knowing: files changed by shell commands Claude ran, such as a package install, aren't rolled back.
The Explore → Plan → Code → Commit lesson said to have a second reviewer on a change before you commit it. 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 don't 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.
Iniciar sesión unirse a la discusión
/code-review
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. If Claude answers inline instead of starting a review, run the command yourself.
Review the changes you just made. Report problems; don't fix anything yet.
Sort each finding into one of three piles:
To ask why, quote the finding back to Claude and ask Claude to check again. For the second finding above, you would type:
You reported that isValidEmail doesn't trim spaces, but line 4 calls trim(). Check again and tell me whether the finding stands.
Whenever you ask for a fix, it's good to ask for evidence with it:
Fix the first finding: don't skip the empty-email test and restore the original assertion. Then run the tests and show me the output.
If a fix eventually grows into a large change of its own, run the review again.
A simple, one-line change often needs a quick glance at the diff and nothing else. You should use a human review and a Claude review when a change is bigger than you could hold in your head, when it touches something sensitive or does something destructive, and before you hand the work to a teammate.
/diff and look for changes you didn't ask for, weaker tests, and new packages or hard-coded values./code-review (or ask in plain words and let Claude start it). The reviewer reports, and Claude doesn't edit unless you ask.