Review code changes the way a careful senior engineer would: catch real problems, skip
nitpicks, and respect the project's existing conventions.
1. Gather the diff
Determine what to review:
- If
$ARGUMENTS names files, a commit, or a range, review that.
- Otherwise review uncommitted work: run
git status and git diff (staged and
unstaged). If the tree is clean, review the most recent commit (git show HEAD).
Read enough surrounding context (not just the diff hunks) to understand each change.
2. Review against what matters
Focus on issues with real consequences, in priority order:
- Correctness: logic errors, off-by-one, wrong conditionals, unhandled cases,
broken control flow.
- Security: injection (command/SQL/XSS), unvalidated input at boundaries, secrets
in code, unsafe deserialization, missing authz checks.
- Silent failures: swallowed errors, empty catches, fallbacks that mask bugs.
- Conventions: does the change follow the patterns already in this codebase?
Match the existing style; don't impose new ones.
- Tests: is new behavior covered? Are edge cases tested?
3. Report by severity
Group findings as Must fix, Should fix, and Consider. For each:
- The
path:line location (clickable).
- What's wrong and why it matters.
- A concrete suggested fix.
Only report things you're genuinely confident about. If a change is clean, say so plainly
rather than inventing concerns. End with a one-line verdict: ship, ship-with-fixes, or
needs-work.
Do not commit, push, or modify files unless the user explicitly asks; this command reviews.
1---2name: judgment3description: Review uncommitted (or specified) changes for bugs, security, and convention drift.4---56Review code changes the way a careful senior engineer would: catch real problems, skip7nitpicks, and respect the project's existing conventions.89## 1. Gather the diff1011Determine what to review:1213- If `$ARGUMENTS` names files, a commit, or a range, review that.14- Otherwise review uncommitted work: run `git status` and `git diff` (staged and15 unstaged). If the tree is clean, review the most recent commit (`git show HEAD`).1617Read enough surrounding context (not just the diff hunks) to understand each change.1819## 2. Review against what matters2021Focus on issues with real consequences, in priority order:22231. **Correctness**: logic errors, off-by-one, wrong conditionals, unhandled cases,24 broken control flow.252. **Security**: injection (command/SQL/XSS), unvalidated input at boundaries, secrets26 in code, unsafe deserialization, missing authz checks.273. **Silent failures**: swallowed errors, empty catches, fallbacks that mask bugs.284. **Conventions**: does the change follow the patterns already in this codebase?29 Match the existing style; don't impose new ones.305. **Tests**: is new behavior covered? Are edge cases tested?3132## 3. Report by severity3334Group findings as **Must fix**, **Should fix**, and **Consider**. For each:3536- The `path:line` location (clickable).37- What's wrong and why it matters.38- A concrete suggested fix.3940Only report things you're genuinely confident about. If a change is clean, say so plainly41rather than inventing concerns. End with a one-line verdict: ship, ship-with-fixes, or42needs-work.4344Do not commit, push, or modify files unless the user explicitly asks; this command reviews.
patrickking67