code-review

Code Review

Reviews a diff against six dimensions (correctness, goal alignment, security, simplification, efficiency, reuse) and reports findings as a severity-ordered table. Every finding is re-checked against the actual code before it ships, so the report doesn't carry a pattern-matched guess dressed up as a bug.

See references/dimensions.md for the six dimensions with worked examples of a real finding vs. a non-finding. See references/findings-format.md for the table schema and a full worked example.

Scope input

Resolve what to review from the request, in this order:

1. No target given — combine three sources: git diff (unstaged, tracked changes), git diff --staged, and untracked files. Plain git diff/git diff --staged never show untracked files — a working tree containing only a brand-new file looks empty to both — so check git status --porcelain for ?? entries and include them (git add -N <file> first makes each show up as an addition in the plain git diff without staging its content). Only fall back to git diff HEAD~1 when all three are empty, and say explicitly that's what's being reviewed instead of silently reporting nothing.
2. A branch name — diff against where it forked from the default branch, not a plain two-dot diff: detect the default branch via git symbolic-ref refs/remotes/origin/HEAD. That ref only exists once a remote's HEAD has been set (git clone usually does this, but a fresh/local-only repo or an unset remote won't have it — verified: a bare git init with no remote raises "not a symbolic ref"); when it's missing, fall back to gh repo view --json defaultBranchRef --jq .defaultBranchRef.name if gh and a GitHub remote are available, otherwise ask the user which branch to diff against rather than guessing main or master. However the default branch was found, find the merge base (git merge-base <default> <branch>), then git diff <merge-base>...<branch>. If the request names a base branch too (a PR targeting a release branch), use that instead of the default branch. Resolve a named base against the remote, not a local branch of the same name: git fetch origin <base>, then git merge-base origin/<base> <branch>. A local main is often stale in a worktree, which pulls other people's commits into the diff, and a release branch often has no local copy at all. A request that names a base but no branch means the current branch (git branch --show-current) against that base, not rule 1.
3. A path — git diff HEAD -- <path> (covers staged and unstaged changes to the path in one call — plain git diff -- <path> shows only unstaged, so a fully-staged change at that path would otherwise look like an empty diff), plus the same untracked-file handling as rule 1, scoped to that path. Same default-branch detection as rule 2 if a branch was also named.
4. A PR number — when gh is available and the repo has a GitHub remote, gh pr diff <number>.