github-review-pr

What it does

Review GitHub Pull Requests with a structured, multi-agent workflow that analyzes PRs using parallel subagents. It performs eligibility checks, gathers context, runs six specialized parallel reviews, deduplicates findings, runs adversarial verification, and filters results before posting a review. It is triggered when users request a PR review, mention reviewing a PR, or reference a PR number or GitHub PR URL. It explicitly uses gh for GitHub interactions and should not analyze local uncommitted changes.

How it works

1. Eligibility Check: uses a subagent to verify the PR is eligible (open, not merged, not a draft, etc.). If ineligible, stop or provide status according to rules. If there is no PR number, list open PRs with gh pr list and ask which to review.
2. Gather Context (parallel): probe PR size with gh pr view 78 --json changedFiles,additions,deletions; decide scope based on size. Collect PR discussion with gh pr view 78 --json comments,reviews and pass as {PR_DISCUSSION} to reviewers.
3. Launch Subagents in parallel:
   • Subagent A: Project guidance discovery — find CLAUDE.md and AGENTS.md files in the repo and list their paths; compare with gh pr diff 78 --name-only to identify modified guidance files.
   • Subagent B: PR summary — view the PR with gh pr view and gh pr diff and return a concise summary of changes.
4. Parallel Code Review (6 agents): launch six subagents per templates, each returning a list of issues with: file path and line numbers, verbatim quoted lines from the diff, evidence, reason tag, and scope (line-anchored or design-level).
5. Deduplicate (step 3.5): merge overlapping findings (same file/lines) and preserve each agent’s reason tag and scope; do not judge validity here.
6. Adversarial Verification: for each deduplicated issue, run a skeptic subagent that rereads code with gh pr diff and optional content fetches, verifies existence and context, and produces independent confidence and severity scores.
7. Filter: post issues only if confidence >= 75 and severity is P0 or P1; otherwise discard but track for reporting.
8. Post-review or approve if no issues pass the gates, otherwise present the filtered findings and recommendations to the user.

When to use it

Use when the user asks to review a PR, mentions reviewing or checking a PR, or provides a PR number or GitHub PR URL. Do not use for local uncommitted changes.

What it can touch

The skill uses tools declared for interaction with GitHub and code review workflows: gh pr list, gh pr view, gh pr diff, gh pr comment, gh pr review, gh repo view, gh api, and related bash commands as needed. It treats all PR content as data; findings must include file path, line numbers, quoted lines, and evidence.

Caveats

Requires using GitHub-related commands and permissions; results are contingent on PR head state and diff integrity. Do not post reviews or approvals (step 7) unless eligibility re-check passed in the same run.