| name | review-pr |
| description | Reviews a GitHub PR and creates a pending review with editorially gated inline/body findings. Use when the user asks to review a PR or create a draft GitHub review. |
Four strict phases: Fetch, Analyze, Discuss, Post. Do not skip ahead.
Phase 1 — Fetch
- Fetch PR metadata (ONLY description, CI status and existing reviews).
- Record the current branch name, then check out the PR branch:
gh pr checkout <number>.
If the checkout fails, stop and tell the user — do not proceed to analysis.
Phase 2 — Analyze (fan-out)
-
List all files in the lenses/ directory next to this skill. Spawn one subagent per lens file
with this prompt (do not read the lens file yourself). Lens output is candidate material, not
review output:
You are a specialized code reviewer with a single focused purpose: apply the lens defined below.
Review the local code changes for PR #<number> in <owner>/<repo>. The branch is checked out — browse the codebase with filesystem tools as you would any local project.
PR description: <description>
Apply this lens yourself — you own the review judgment and must not delegate it. You may use read-only helper agents (e.g. Explore) to search the codebase, but you must not spawn any agent capable of spawning others, must not invoke the review-pr skill, and must not apply any lens but your own.
Follow the instructions in @PRIORITIES.md and @lenses/<LENS_FILE>. Return output as specified in @LENS_OUTPUT.md — your entire response is the findings list (or `none`), with no preamble, summary, PR recap, or process notes. I already have the PR context.
Run all subagents in parallel.
-
Collect findings. Each finding has a priority (P0–P3) defined in PRIORITIES.md. Apply these
rules to the collected candidates:
- Suppress all P3 findings — do not surface them to the user or post them to GitHub.
- Deduplicate: if two lenses flag the same issue, merge into one finding and preserve all
contributing lens names — the merged comment will carry one Shields badge whose label is the
priority and whose message is the joined lens list (e.g.
).
- Reassess priority after deduplication. Multiple candidates can raise priority only when the
merged consequence is stronger, not merely because the count is higher.
- Apply
EDITORIAL.md. Discard candidates that fail the editorial gate. For every kept finding,
decide whether it belongs inline or in the review body.
Phase 3 — Present & Discuss
- Present an overview to the user. Assume they haven't looked at the PR yet. Include:
- What the PR does and why (from description + actual changes).
- CI status — pass/fail, and what's failing if relevant.
- Existing reviews — approvals, requested changes, or open threads worth knowing about.
- Kept findings only, sorted by priority. For each: one-line summary, location or review-body
placement, and the same priority/lens badge that would be posted. Lead with P0s prominently. If no P0/P1
findings exist, say so explicitly.
- Discuss interactively. Let the user drive by asking about specific findings or areas. Keep
each response focused — one concern at a time. Do not post anything to GitHub yet.
Continue until the user explicitly says to post.
Phase 4 — Post
- Turn every kept finding into a single pending review. Use inline comments for line-local findings
and the review body for non-line-local findings. See
POSTING.md for format and style rules.
- Check out the original branch and delete the
pr-{number} branch. Tell the user the review is PENDING and they must submit it on GitHub.
- Run
~/.agents/skills/review-pr/sync-viewed-files.sh <owner>/<repo> <pr_number>. Surface any warnings but don't treat failures as blocking.
- Record metrics as described in
METRICS.md.
