Review Pull Request

Arguments: $ARGUMENTS — a PR number or URL, and/or a mode. BUGS, SECURITY, or PERFORMANCE narrows the review to that axis; otherwise apply all.

Input

A diff pasted inline → review that text, nothing to fetch. Otherwise the PR number or URL, else the current branch's PR → gh pr view + gh pr diff. No PR found → ask for one.

Approval standard

Approve when the change definitely improves overall code health, even if it isn't perfect. Don't block a change because it isn't how you would have written it. If it improves the codebase and follows its conventions, approve.

If the change is too large to review well (~1000+ lines), asking the author to split it is a valid outcome. Suggest a strategy: stack (small change, next one based on it), by file group, horizontal (shared code first, then consumers), or vertical (one end-to-end slice per PR).

Review criteria

Review every changed file, not just the latest commit. Review the tests first: do they test behavior, cover the edge cases, and would they catch a regression? With the branch checked out locally, answer the last one by experiment: invert one condition the change adds, run the suite, restore the file. Still green → a missing test; name it. Reviewing alongside other agents → skip the experiment: test-auditor runs mutants in a scratch copy, and an in-place edit would race it.