Review PR

Find what would hurt in production, explain it so the author can fix it fast, and say it kindly.

1. Get the diff

base=$(git symbolic-ref --short refs/remotes/origin/HEAD 2>/dev/null | sed 's|^origin/||')
[ -n "$base" ] || base=$(git branch --list main master | head -1 | tr -d ' *')

<base> is the remote's default branch (snippet above), falling back to main or master.

If <base> comes back empty (no origin/HEAD and no main or master), ask the user which branch is the base before going on.

• PR number or URL with gh → gh pr view <n> (title, body, linked issue), gh pr diff <n>, and git fetch -f origin pull/<n>/head:pr-<n> so you can read the PR's files with git show pr-<n>:<path>.
• PR number without gh → GitHub: git fetch -f origin pull/<n>/head:pr-<n>; GitLab: git fetch -f origin merge-requests/<n>/head:mr-<n>; otherwise ask for the branch name.
• Branch → git log <base>..<branch> and git diff <base>...<branch>.
• Nothing given → the current branch against its base.

gh account: the user may have several gh accounts, and the active one may not see this repo. Before the first gh call, list each account's access:

for u in $(gh auth status 2>&1 | sed -n 's/.*account \([^ ]*\).*/\1/p'); do echo "$u $(GH_TOKEN=$(gh auth token --user "$u") gh repo view --json viewerPermission -q .viewerPermission 2>/dev/null)"; done; true

Pick the first account with ADMIN, MAINTAIN or WRITE, else one with READ or TRIAGE. If none shows a permission, skip every gh call. Run every gh call as that account, GH_TOKEN=$(gh auth token --user <account>) gh ..., with 2>/dev/null. Never run gh auth switch. If git fetch fails with "Repository not found", retry it with that account's token: git -c credential.helper= -c 'credential.helper=!f(){ echo username=<account>; echo "password=$(gh auth token --user <account>)"; }; f' fetch ....

Read the description first and judge the code against what it claims to do.

2. Read beyond the diff

For each changed function, read the whole file at the PR's version (git show <branch>:<path>) and cite line numbers from that version. Never check out or switch the user's branch. Find its callers with grep. Bugs hide in what the diff does not show: callers relying on old behavior, places that also needed a change, tests that no longer test anything.

3. Check, in this order

1. Correctness: logic errors, = vs ===, off-by-one, null or empty input, units, async/await, error paths.
2. Security: injection, secrets in code, missing auth checks, unsafe input.
3. Data: migrations, backwards compatibility, breaking API changes.
4. Tests: is the new behavior covered, and do the tests assert something real?
5. Readability: names, dead code — only when it will cause real confusion.

Skip style nits a linter would catch.

4. Report

**Verdict:** Approve / Approve with comments / Request changes

**Must fix**
1. `path:line` — <problem>. <concrete input → wrong result>. Suggest: <fix>.

**Should fix**
1. `path:line` — ...

**Nice to have** (max 3)

**Good:** <one specific thing done well>

Leave out empty sections. Every finding has path:line, a concrete failure, and a suggestion.

5. Post — only after a yes

Offer to post only when a PR/MR exists; otherwise the review stays in chat. To post: gh pr review <n> --comment --body-file <file>. Never approve or request changes on GitHub without an explicit yes.

Rules

• Read-only: never edit, commit, or push the author's code during a review.
• Don't run, install, or test the PR's code unless the user says so — derive failing inputs by reading the code. You may offer to run it.
• About the code, not the person. Ask when unsure: "Could this be null when…?"
• No finding without evidence. Say "not sure" rather than guess.