| name | review-pr |
| license | MIT |
| description | Review someone else's GitHub PR as a Staff Engineer and post a high-precision review — mechanical grounding (CI, local verification), focused design + security passes, calibrated severity labels, inline comments with suggestion blocks. Use when asked to review a PR, give feedback on a PR, or act as a code reviewer. |
| compatibility | Requires the GitHub CLI (`gh`) authenticated with access to the PR's repository |
| inputs | [{"name":"pr","required":false,"description":"PR number, URL, or branch name (default: the open PR for the current branch)"},{"name":"post","required":false,"description":"Default true: submit the review to GitHub. When false, write the full review to a local report instead of posting."},{"name":"max_comments","required":false,"description":"Cap on inline comments, highest severity first (default: 10). Prevents alert fatigue on large PRs."},{"name":"comment_prefix","required":false,"description":"Prefix for every posted comment body, e.g. a bot identity like 'ReviewBot: ' (default: none)"},{"name":"run_local_verification","required":false,"description":"Default 'auto': check out and build/test the PR branch locally only when CI is absent or not green, and only if the working tree is clean. 'never' skips local execution (rely on CI); 'always' forces it. Running PR code executes untrusted code — use 'never' for PRs from untrusted authors unless sandboxed."}] |
Review PR
Review someone else's pull request and deliver the kind of review a rigorous
human Staff Engineer would: grounded in evidence, labeled by severity, and
quiet about everything that doesn't matter.
The prime directive is precision over recall. Developer trust in a
reviewer collapses non-linearly with false positives — a handful of wrong or
noisy comments and every future comment gets skimmed. A review that surfaces
three real issues beats one that surfaces three real issues buried in ten
speculative ones. When unsure whether an issue is real: it isn't. Drop it.
The governing standard (Google's, and ours): favor approval once the PR
definitely improves the overall code health of the system, even if it isn't
perfect. You are reviewing for "better", not "perfect".
Phase 0 — Gather context
Run the bundled context fetcher from the repo root (read-only):
// turbo
bash scripts/fetch-pr-context.sh <pr>
It resolves the PR (argument, or the current branch's open PR), and writes:
/tmp/pr-context.json — title, body, author, base/head refs, draft state,
changed files with add/delete counts, CI check rollup/tmp/pr-threads.json — all existing review threads with resolution state
Then gather what the script can't:
- The diff:
gh pr diff <number> (or git diff base...head if checked
out). Note which lines belong to diff hunks — GitHub rejects inline
comments outside them.
- Intent: read the PR title, description, and any linked issue
(
Fixes #N / Closes #N → gh issue view N). If the description is
empty, reconstruct intent from the commit messages. You cannot judge
"does this do what it intends, and is that good for this codebase?"
without knowing the intent. If intent is genuinely unrecoverable, say so
in the review summary and review what the code does.
- Repo standards: read the repo's
AGENTS.md / CONTRIBUTING.md /
style or architecture docs for the touched areas. Comments grounded in
the repo's own documented rules ("CONTRIBUTING.md requires X here")
carry far more weight than generic best practices — prefer them.
- Existing feedback (from
/tmp/pr-threads.json): what other reviewers
and bots have already said. Never re-raise a point that has already been
made, resolved, or explicitly dismissed on this PR.
