Say "Review What We've Done" Before Committing to Catch Mistakes Early
After a long session of edits, Claude might have introduced subtle mistakes — a typo in a variable name, a missing import, an edge case it skipped, or an inconsistency between two files it edited separately. Catch it before you commit.
"Review all the changes we've made in this session.
Check for mistakes, inconsistencies, and anything you missed."
Claude runs git diff, re-reads every changed file, and reviews its own work with fresh eyes. It catches things like:
- A function it renamed in one file but forgot in another
- An import it added that's unused, or one it forgot to add
- A validation rule that doesn't match the migration it just wrote
- A test that tests the old behavior instead of the new behavior
- A hardcoded value that should be a config reference
This is especially valuable after:
# Multi-file refactors
"We just refactored the auth system across 15 files.
Review the diff for anything we missed."
# Feature implementations
"Review the feature we just built. Check the controller, model,
migration, and tests for consistency."
# Bug fixes
"Review the fix we just made. Does it actually solve the reported
problem without introducing new issues?"
Make it a habit at the end of every productive session:
# After building something
"Review the diff, then run the tests"
# Before committing
"Review what changed, fix any issues, then write a commit message"
# Before opening a PR
"Review all changes since main. Would you approve this PR?"
Claude is better at reviewing its own work than you'd think — the review prompt forces it to re-examine decisions it made earlier in the session, when it might have been focused on a different part of the problem.
You review other people's code before it ships. Review Claude's code too — ask it to self-check before you commit.
via Claude Code
Log in to leave a comment.
Set up Claude Code as an automated reviewer in your CI pipeline — on every pull request, it reads the diff, checks for bugs, security issues, missing tests, and convention violations, then posts its findings as a PR comment. Your human reviewers get a head start because the obvious issues are already flagged before they look.
Before deploying, tell Claude to read your project — migrations, environment variables, queue workers, scheduled tasks, caching, third-party integrations — and generate a deployment checklist that's specific to your app. Not a generic "did you run migrations?" list, but one that knows YOUR infrastructure and catches the things YOUR deploy can break.
Instead of writing a README from memory or copying a template, tell Claude to read your project and generate one that's actually accurate — real setup instructions from your config, real architecture from your directory structure, real API examples from your routes, and real prerequisites from your dependency files.