Two hats: author and reviewer
Claude is a strong author, but it's an equally strong reviewer. Review is where a coding agent quietly saves you the most time: catching the off-by-one, the missing await or the unhandled null before your teammates (or your users) do.
/code-review
The built-in /code-review reviews your current diff, a branch, a pull request number or a path. It looks for correctness bugs and reports findings ranked by severity.
/code-review # review the current changes
/code-review 482 # review pull request #482
/code-review --fix # apply the fixes after reviewingFor a deep multi-agent review of a branch in the cloud, /code-review ultra launches a more thorough (and billed) review.
Prompts that produce useful reviews
A vague "review this" gets you vague style comments. Tell Claude what to look for and what to skip:
review the diff against main for correctness only: race conditions, error handling,
and edge cases around empty carts. skip style and naming.If you're checking against a spec, say so, and say "skip style". Reviews get sharper when the reviewer knows the target.
The session that wrote the code is biased toward believing it works. For important changes, review in a fresh context: run /code-review, start a second session, or ask for a subagent reviewer. A second session makes a great reviewer.
Security reviews
/security-review focuses specifically on vulnerabilities in your pending changes: injection, auth mistakes, secrets in code and unsafe deserialization. Treat it as a smart first pass, not a replacement for your security process.
Review in the pull request
Teams can go further: Claude can review pull requests on GitHub and comment inline. You'll set up GitHub Actions and managed Code Review in Unit 8.
Check your understanding
What makes a review prompt produce more useful findings?
Why review in a fresh context?
Which command focuses on vulnerabilities in pending changes?
What does /code-review --fix do?