| name | handle-pr |
| description | Review an incoming PR end-to-end — strict local review, drafted GitHub review, post after confirmation |
| argument-hint | <pr-number> |
| allowed-tools | Task, Bash, Read, Glob, Grep, Write, mcp__github__get_pull_request, mcp__github__get_pull_request_files, mcp__github__create_pull_request_review |
Handle PR
Review an incoming pull request end-to-end: a strict local review against
REVIEW_CRITERIA.md (including scope and spec satisfaction), distilled into a
GitHub review draft, posted only after user confirmation. Internal and
external PRs are treated the same.
For later rounds — after the author responds to a posted review — use
/follow-up-review <number> instead (it is round-aware: it verifies the prior
requested changes against the delta and reads the author's replies).
/address-review is the author-side counterpart, for feedback on a PR you
authored — not for re-reviewing an incoming PR.
Arguments
/handle-pr <pr-number>
Workflow
Step 1: Pre-Checks
Fetch the PR (mcp__github__get_pull_request). Check before any deep
review:
- Scope: does the PR address exactly one concern (CONTRIBUTING.md: one
PR, one concern)? If it clearly bundles unrelated changes, the review can
short-circuit: the primary finding is "split this PR", detailed findings
are secondary
- Linked spec/issue: identify the linked issue from the PR body or
branch name. If it links a
spec issue, that spec is the verification
target
- CI status: note failing checks (
gh pr checks <number>)
Step 2: Local Review
Spawn a subagent (Task tool, subagent_type: "general-purpose"):
- description:
Review PR locally
- prompt:
Read the skill definition at .claude/skills/code-review/SKILL.md and execute it fully in PR mode for PR #<number>. Apply all eight review areas in REVIEW_CRITERIA.md strictly — including Scope (one PR, one concern) and Spec Satisfaction against issue #<linked-issue>. This is an incoming PR; hold it to the project's full standard: tests, guidelines, commit messages, documentation.
Verify: the review file review-pr<number>-*.md exists in .ai/.
Step 3: Draft the GitHub Review
Spawn a subagent:
- description:
Draft GitHub review
- prompt:
Read the skill definition at .claude/skills/pr-review/SKILL.md and execute it fully for PR #<number>. Use the existing code review file in .ai/ as the basis. Write the review file for preview — do not post.
Verify: the pr-review-*.md draft exists.
Step 4: Confirmation Gate
Present to the user:
- Verdict (APPROVE / COMMENT / REQUEST_CHANGES) and why
- The full review body and inline comments from the draft
- Anything noteworthy from pre-checks (scope, CI, missing spec link)
Wait for confirmation. The user may edit findings, downgrade/upgrade the
event, or decide not to post.
Step 5: Post
On confirmation, post via the /post-review skill pattern (read
.claude/skills/post-review/SKILL.md): parse the draft, map inline comments
to diff lines, post with mcp__github__create_pull_request_review.
Step 6: Report
- Posted review URL and event type
- If REQUEST_CHANGES: note that the 7-day response window from
CONTRIBUTING.md starts now —
/check-prs tracks it, /takeover-pr
applies after it lapses
