PR Code Review

Comprehensive pull request review using parallel specialized reviewers. Each reviewer focuses on one aspect of code quality, producing confidence-scored findings filtered to surface only high-signal issues.

Core principle: Multiple focused reviewers catch more than one generalist. Confidence scoring eliminates noise.

When to Use

Reviewing a pull request before merge
When asked to "review this PR" or "code review"
Before approving code for production
Re-reviewing a PR after the author addresses review comments

Don't use for:

Reviewing local uncommitted changes (review the diff directly instead)
Architecture review of entire codebase (too broad for PR review)

Workflow

digraph review {
    rankdir=TB;
    gather [label="1. Gather Context" shape=box];
    needed [label="Review needed?" shape=diamond];
    skip [label="Skip" shape=box];
    dispatch [label="2. Dispatch Parallel Reviewers" shape=box];
    collect [label="3. Collect & Filter ≥75" shape=box];
    report [label="4. Report" shape=box];

    gather -> needed;
    needed -> skip [label="closed/draft/trivial"];
    needed -> dispatch [label="yes"];
    dispatch -> collect;
    collect -> report;
}

Step 1: Gather Context

Collect before dispatching reviewers:

PR diff: git diff <base>...<head> (or fetch via PR API)
Changed file list: git diff --name-only <base>...<head>
Project guidelines: Look for CLAUDE.md, AGENTS.md, .cursorrules, CONTRIBUTING.md, or similar
PR description: Title, body, linked issues

Skip review if: PR is closed, draft, or only touches lockfiles/generated code/CI config.

Step 2: Dispatch Parallel Reviewers

Launch one subagent per applicable review aspect. Each subagent gets:

The PR diff (or relevant file portions)
Full content of changed files for context
Project guidelines (if found)
Aspect-specific instructions from [references/](references/)
The output format below

Select applicable aspects based on what changed:

Aspect	When to Include	Reference
Bug Detection	Always	[bug-detection.md](references/bug-detection.md)
Error Handling	Code with try/catch, error callbacks, fallbacks	[error-handling.md](references/error-handling.md)
Type Design	New or modified type/interface/class definitions	[type-design.md](references/type-design.md)
Test Coverage	Always (flag missing tests even if none in diff)	[test-coverage.md](references/test-coverage.md)
Comment Quality	Files with doc comments, JSDoc, docstrings	[comment-quality.md](references/comment-quality.md)
Guidelines Compliance	When project guidelines file exists	[guidelines-compliance.md](references/guidelines-compliance.md)

Subagent prompt template:

You are reviewing a pull request for [ASPECT].
Only report issues introduced by THIS PR, not pre-existing problems.

## PR Context
- Title: [title]
- Description: [body]
- Changed files: [file list]

## Project Guidelines
[guidelines content, or "No project guidelines found."]

## Diff
[diff content]

## Changed File Contents
[full file contents for context around the diff]

## Review Instructions
[paste content from the corresponding references/ file]

## Output Format
For each issue, report as structured data:
- file: path/to/file
- line: line_number
- confidence: 0-100
- severity: critical | important | minor
- issue: What is wrong
- impact: Why it matters if not fixed
- suggestion: Specific fix recommendation

Step 3: Collect and Filter

Merge findings from all reviewers. Discard anything with confidence < 75.

Use git blame to verify flagged lines were actually changed in this PR. Downgrade or drop findings on pre-existing code.

Step 4: Report

## Review Summary
Reviewed [N] files, [M] lines changed across [K] review aspects.

## Critical Issues (confidence 90-100)
### [file:line] — Issue title (confidence: N)
Description of the issue.
**Impact:** What breaks if not fixed.
**Suggestion:** Specific fix.

## Important Issues (confidence 75-89)
### [file:line] — Issue title (confidence: N)
Description of the issue.
**Impact:** What could go wrong.
**Suggestion:** Specific fix.

## Positive Observations
- [Strengths worth noting]

Posting the Review on GitHub

When the review targets a GitHub PR, submit a formal review — not a plain comment.

Use inline comments on specific lines of the diff for each finding. Include the confidence score and suggestion directly in the inline comment.

Submit a review verdict:

Approve if no findings at confidence ≥75 remain after filtering
Request Changes if any critical (90-100) or important (75-89) findings exist

Use your platform's PR review API (e.g., gh api for GitHub CLI, or equivalent) to post the review with inline comments and a verdict in a single review submission. Do not post findings as individual standalone comments.

Re-Review: Resolving Addressed Comments

When re-reviewing a PR (the author pushed fixes and re-requested review), resolve inline review threads that have been addressed before running the normal review flow on new changes.

Re-Review Workflow

digraph rereview {
    rankdir=TB;
    detect [label="Detect re-review" shape=diamond];
    fetch [label="Fetch open threads" shape=box];
    examine [label="Examine each thread\nagainst current code" shape=box];
    resolve [label="Resolve addressed threads" shape=box];
    review [label="Run normal review\non new changes" shape=box];

    detect -> fetch [label="has prior review"];
    detect -> review [label="first review"];
    fetch -> examine;
    examine -> resolve;
    resolve -> review;
}

Step R1: Detect Re-Review

A re-review is indicated when:

The user says "re-review", "follow-up review", or "check if comments are addressed"
The PR already has review threads from a prior review

Step R2: Fetch Open Review Threads

Use the GraphQL API to list all unresolved review threads on the PR:

gh api graphql -f query='
  query($owner: String!, $repo: String!, $pr: Int!) {
    repository(owner: $owner, name: $repo) {
      pullRequest(number: $pr) {
        reviewThreads(first: 100) {
          nodes {
            id
            isResolved
            isOutdated
            path
            line
            comments(first: 5) {
              nodes {
                body
                author { login }
                createdAt
              }
            }
          }
        }
      }
    }
  }
' -f owner='{owner}' -f repo='{repo}' -F pr=PR_NUMBER

Filter to only unresolved threads (isResolved: false).

Step R3: Examine Each Thread Against Current Code

For each unresolved thread:

Read the current content of the file at the path indicated by the thread
Read the original review comment to understand what was flagged
Check if the issue described in the comment has been addressed:

- The problematic code was changed or removed - The suggested fix (or equivalent) was applied - The thread is marked isOutdated (the diff line no longer exists) — likely addressed

Judgment criteria:

If the code at the flagged location clearly addresses the concern → resolved
If the thread is isOutdated and the surrounding code looks correct → resolved
If the issue persists unchanged → unresolved (leave open)
If partially addressed or addressed differently than suggested → use judgment; resolve if the concern is no longer valid

Step R4: Resolve Addressed Threads

For each thread confirmed as addressed, resolve it via GraphQL:

gh api graphql -f query='
  mutation($threadId: ID!) {
    resolveReviewThread(input: { threadId: $threadId }) {
      thread { isResolved }
    }
  }
' -f threadId='THREAD_ID'

Do not resolve threads that are still valid. Only resolve threads where the underlying issue has been fixed.

Step R5: Report and Continue

After resolving addressed threads, report what was resolved and what remains:

## Re-Review: Comment Resolution

### Resolved (N threads)
- [file:line] — [brief description of original issue] ✓ Fixed
  
### Still Open (M threads)
- [file:line] — [brief description] — still present / not fully addressed

### Continuing with full review on new changes...

Then proceed with the normal review workflow (Steps 1–4) on any new changes since the last review.

Confidence Scoring

Every finding gets a 0-100 confidence score:

Range	Meaning	Action
90-100	Definite bug, security issue, or explicit guideline violation	Must fix
75-89	Likely issue, warrants attention	Should fix
50-74	Possible concern but uncertain	Filtered out
0-49	Nitpick, pre-existing, or false positive	Filtered out

Confidence adjustments

Lower confidence when:

Issue existed before this PR (check git blame)
Surrounding code shows intentional pattern
Would be caught by linter or type checker
Ambiguous without runtime context
Style preference rather than correctness

Raise confidence when:

Clear logic error in new code
Security vulnerability introduced by this PR
Explicit violation of stated project guidelines
Missing error handling for obvious failure modes
Test gap for critical code path

False Positive Prevention

DO NOT report:

Pre-existing issues not introduced by this PR
Code following an established project pattern (even if unusual)
Style nitpicks not in project guidelines
Issues linters/formatters/type checkers will catch
Suggestions to add handling where the framework guarantees safety
Generic "best practice" advice not tied to specific risk in this diff

Common Mistakes

Mistake	Correction
Reviewing all code in changed files	Only review new/modified lines and their immediate context
Reporting pre-existing issues	Use git blame to verify issue is from this PR
Flooding with low-confidence findings	Enforce the ≥75 threshold strictly
Generic advice ("add more tests")	Specific gaps ("missing test for error path at auth.ts:47")
Skipping aspects because PR seems simple	Always run Bug Detection and Test Coverage at minimum

pr-code-review

Installation

Stronger alternatives

Similar popular skills

Also in this package

Agent compatibility

Repository health

Skill metadata

Package contents

History

SKILL.md