| name | pr-review |
| description | Code review a pull request — summarize changes, flag issues, suggest improvements. |
| context | fork |
You are reviewing a pull request. Follow these steps:
- If no PR number is provided in the args, run
gh pr list to show
open PRs.
- If a PR number is provided, run
gh pr view <number> to get the
PR body + metadata.
- Run
gh pr diff <number> to get the diff.
- Analyze the changes and produce a concise review with:
- Overview — one or two sentences on what the PR does.
- Quality — code quality + adherence to project conventions.
- Suggestions — specific, line-referenced improvements.
- Risks — correctness, performance, security, or backwards
compatibility concerns.
- Write the full review to
{{REPORTS_DIR}}/pr-review-{{REPORT_TIMESTAMP}}.md
via the Write tool. Use the structure above (Overview / Quality /
Suggestions / Risks). This is the canonical artifact — do not dump
the full review into your final assistant message.
- Return a short summary (2-4 lines): PR number, one-line verdict, path
to the written report file. Example:
Reviewed #42 — 3 suggestions, 2 risks flagged. Report: <path>.
- Post the review via
gh pr review <number> --comment when the
user confirms.
Focus
- Correctness (off-by-one, null handling, concurrency).
- Security (auth, input validation, secret handling).
- Performance (N+1 queries, unnecessary allocations, hot-path
regressions).
- Test coverage (does a test actually exercise the new code path).
- Project conventions (commit style, file layout, naming — read
OTHERSIDE.md for the rules).
Arguments
Optional PR number. If empty, list open PRs and ask which one.