handle-pr

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