Code review
Find what would break, not what you would have written differently.
Steps
- Get the diff. For a PR:
gh pr diff <number>andgh pr view <number> --json title,body. For local work:git diff <base>...HEAD. - Read the linked issue or the PR summary first so the review judges the change against its own goal.
- Walk the diff file by file and ask, for each hunk: what input makes this wrong, what happens on the error path, what test would have caught it.
- Check the tests: does a new branch have an assertion that fails without the change? A test that only exercises the happy path is a finding.
- Check the edges of the change: callers of a renamed or re-typed symbol, migrations against existing data, workflows that run the changed command.
Report
One finding per line, most severe first:
<severity> <path>:<line> - <what is wrong> - <input or state that triggers it>
Severities: bug (wrong result or crash), risk (unsafe under a plausible input),
test (missing or weak coverage), nit (style, only if it hides a bug).
End with one line: No blocking findings. or Blocking: <count>. Do not post to GitHub unless
the user asked; when asked, use gh pr review with the findings as the body.