review

Review my changes

Self-review the uncommitted diff from three angles before committing. Findings only — no auto-fix unless asked.

A second pair of eyes on the code you just wrote, before /commit. The risk in solo work is that nobody else ever reads the diff — this command is that reader. Output is a concrete findings list; you decide what to fix.

Input: an optional scope.

• none → the uncommitted diff (staged + unstaged + untracked)
• staged → only staged changes
• HEAD~N → the last N commits on this branch
• <sha>..<sha> → a specific range

---

Step 1 — Gather the diff

ARG="${1:-}"
if [ -z "$ARG" ]; then
  SCOPE="uncommitted"
  git diff --staged > /tmp/review.patch
  git diff >> /tmp/review.patch
  for f in $(git ls-files --others --exclude-standard); do
    printf -- '--- /dev/null\n+++ b/%s\n' "$f" >> /tmp/review.patch
    sed 's/^/+/' "$f" >> /tmp/review.patch
  done
elif [ "$ARG" = "staged" ]; then
  SCOPE="staged"; git diff --staged > /tmp/review.patch
elif [[ "$ARG" =~ ^HEAD~ ]]; then
  SCOPE="$ARG"; git diff "$ARG..HEAD" > /tmp/review.patch
else
  SCOPE="$ARG"; git diff "$ARG" > /tmp/review.patch
fi
echo "[SCOPE] $SCOPE"

If the diff is empty: print No changes to review. and stop.

For any file changed by more than ~20 lines, read the whole file, not just the patch. Reviewing a patch without context produces false positives.

Step 2 — Review from three angles

Examine the diff three times, each with a different hat. (If your tool can run sub-agents in parallel, run these three concurrently; otherwise do them in sequence.) Every finding must carry file:line + why it's a problem + a concrete fix.

1. Logic auditor — find real bugs: null/undefined dereferences, unhandled edge cases (empty/zero/negative/boundary), races and stale closures, swallowed or missing error handling, off-by-one, wrong state updates, type assertions that can be false at runtime.

2. Design critic — find architecture/consistency issues: names that fight the codebase convention, logic duplicated from elsewhere (grep to confirm), business logic stuffed into a UI/handler layer, a new pattern that clashes with the existing one in the same area, leaky module boundaries, weak types (any, casts hiding a real type).