GitHub Review Skills for Claude Code — triage and review PRs with difficulty, CI, and correctness scoring

README.md

GitHub Review Skills for Claude Code

Three Claude Code skills for triaging and reviewing GitHub pull requests. They use the gh CLI under the hood.

Skill	Description
/github-review-requests	List open PRs where your review has been requested
/github-review-queue	Triage all pending PRs with difficulty, CI, and correctness scores
/github-review-pr	Deep-dive analysis of a single PR

Prerequisites

• Claude Code installed and working
• GitHub CLI (gh) installed and authenticated (gh auth login)

Installation

Each skill lives in its own directory under ~/.claude/skills/. Download and install all three with:

mkdir -p ~/.claude/skills/github-review-pr \
         ~/.claude/skills/github-review-queue \
         ~/.claude/skills/github-review-requests

GIST_URL="GIST_URL_PLACEHOLDER"

curl -sL "${GIST_URL}/raw/github-review-pr.md" \
  -o ~/.claude/skills/github-review-pr/SKILL.md

curl -sL "${GIST_URL}/raw/github-review-queue.md" \
  -o ~/.claude/skills/github-review-queue/SKILL.md

curl -sL "${GIST_URL}/raw/github-review-requests.md" \
  -o ~/.claude/skills/github-review-requests/SKILL.md

Or manually: download each .md file from this gist and place it at the corresponding path as SKILL.md:

~/.claude/skills/
├── github-review-pr/
│   └── SKILL.md          ← github-review-pr.md
├── github-review-queue/
│   └── SKILL.md          ← github-review-queue.md
└── github-review-requests/
    └── SKILL.md          ← github-review-requests.md

Usage

Start a Claude Code session and run any of the skills:

/github-review-requests
/github-review-queue
/github-review-pr https://github.com/owner/repo/pull/123

github-review-pr.md

name	github-review-pr
description	Deep-dive analysis of a single PR with difficulty, CI, and correctness scoring

GitHub Review PR

Perform a detailed review analysis of a single pull request.

Usage

/github-review-pr <pr-url-or-number> [--repo <owner/repo>]

• If a full URL is provided, extract the repo and PR number from it
• If just a number is provided, --repo is required

Instructions

Step 1: Parse arguments

Extract the repository (owner/repo) and PR number from the arguments.

• URL pattern: https://github.com/<owner>/<repo>/pull/<num>
• If just a number and --repo is given, use those directly
• If neither works, ask the user to provide a valid PR URL

Step 2: Gather PR data

Run all of these in parallel:

1. PR metadata:

   gh pr view <number> --repo <repo> \
     --json title,author,body,additions,deletions,\
   changedFiles,files,labels,createdAt,baseRefName,\
   headRefName
   

2. Full diff:

   gh pr diff <number> --repo <repo>
   

3. CI checks:

   gh pr checks <number> --repo <repo> \
     --json name,state,link,workflow,description
   

4. PR comments and review comments:

   gh api repos/<repo>/pulls/<number>/comments \
     --jq '.[] | {user: .user.login, body: .body,
     path: .path, line: .line}'
   

   gh pr view <number> --repo <repo> --json comments \
     --jq '.comments[] | {author: .author.login,
     body: .body}'
   

Step 3: Review Difficulty Score (0-100)

Compute a difficulty score using these factors. Show the breakdown so the user understands the reasoning.

Size (40% weight)

• Lines changed = additions + deletions
• <50 lines → 95
• 50-100 lines → 80
• 100-200 lines → 65
• 200-400 lines → 45
• 400-800 lines → 25
• 800+ lines → 10

File spread (20% weight)

• 1-2 files → 95
• 3-5 files → 75
• 6-10 files → 50
• 11-20 files → 30
• 20+ files → 10

Change complexity (40% weight)

Analyze the diff content and score based on:

• File types changed:
  • Tests, docs, config, CI → easier (+15)
  • UI/styles only → moderate (+5)
  • Core logic, data models, APIs → harder (-10)
  • Database migrations, auth, concurrency → hardest (-20)
• Change pattern:
  • Additions only (new code) → easier (+10)
  • Small focused edits → moderate (+5)
  • Refactors touching many functions → harder (-10)
  • Deletions mixed with additions → moderate (0)
• Cognitive complexity signals in diff:
  • Nested conditionals (3+ levels) → -5 per occurrence
  • New error handling paths → -3 per path
  • Concurrency primitives (locks, channels, async) → -10
  • Type/interface changes that ripple → -5

List each file changed with:

• Filename
• Lines added / removed
• Brief complexity note (1 sentence)

Step 4: CI Status Diagnosis

Report each check with its status. For any failing checks:

1. Note the check name and failure
2. Compare the failing check's area to the PR's changed files
3. Classify as:
   • author-caused: The failure is in the same area as the PR changes, or the test name references code that was modified
   • likely flaky: The failure is in an unrelated area, or the test is known to be intermittent, or it's an infrastructure/timeout failure
   • unclear: Not enough information to determine

If checks are failing, try to get logs:

gh run view <run-id> --repo <repo> --log-failed 2>&1 \
  | tail -100

Extract the run ID from the detailsUrl of the failing check.

Show a summary table:

Check	Status	Diagnosis

And an overall CI verdict.

Step 5: Correctness Score (0-100)

Analyze the diff in detail. Read surrounding file context when needed to understand the change (use gh api or checkout commands to fetch specific files if necessary).

Score based on these factors, showing the breakdown:

Logic correctness (40% weight)

• Does the code do what the PR description says?
• Are there obvious logic errors?
• Are edge cases handled (nulls, empty inputs, errors)?
• Are return values and error codes correct?

Test coverage (25% weight)

• Are there new/updated tests for the changed behavior?
• Do the tests cover the happy path and key edge cases?
• If no tests, is the change trivial enough to not need them?

Consistency (20% weight)

• Does the code follow existing patterns in the repo?
• Are naming conventions followed?
• Is the code style consistent with surrounding code?

Completeness (15% weight)

• Are all necessary changes included? (e.g., if adding a new API field, is it in the schema, handler, tests, and docs?)
• Are there TODO/FIXME/HACK comments that suggest incomplete work?
• Does the PR description mention anything not reflected in the diff?

Step 6: Display results

Output a structured report:

## PR #<number>: <title>
**Author**: <login> | **Created**: <date>
**Base**: <base> ← <head>

### Summary
<2-3 sentence summary of what this PR does>

### Review Difficulty: <score>/100 (<label>)
| Factor          | Score | Notes              |
|-----------------|-------|--------------------|
| Size            | xx    | <lines> lines      |
| File spread     | xx    | <n> files          |
| Complexity      | xx    | <brief note>       |
| **Weighted**    | **xx**|                    |

#### Files Changed
- `path/to/file.ts` (+10/-3) — <complexity note>
- ...

### CI Status: <verdict>
| Check           | Status | Diagnosis          |
|-----------------|--------|--------------------|
| ...             | ...    | ...                |

### Correctness: <score>/100 (<label>)
| Factor          | Score | Notes              |
|-----------------|-------|--------------------|
| Logic           | xx    | <brief note>       |
| Tests           | xx    | <brief note>       |
| Consistency     | xx    | <brief note>       |
| Completeness    | xx    | <brief note>       |
| **Weighted**    | **xx**|                    |

### Key Observations
- <bullet points of notable findings, concerns,
  or positive signals>

### Suggested Focus Areas
- <what to pay closest attention to during review>

github-review-queue.md

name	github-review-queue
description	Triage all PRs awaiting your review with difficulty scores, CI status diagnosis, and correctness scores

GitHub Review Queue

Fetch all open PRs requesting your review, analyze each one, and produce a triage dashboard.

Instructions

Step 1: Fetch PRs requesting your review

Run:

gh search prs --review-requested=@me --state=open \
  --json number,title,repository,url,author,createdAt

If no PRs are found, tell the user they have no pending review requests and stop.

Step 2: Gather data for each PR

For each PR, run these commands in parallel (use the Bash tool with multiple parallel calls). Replace <repo> with repository.nameWithOwner and <number> with the PR number.

1. PR details and diff stats:

   gh pr view <number> --repo <repo> \
     --json additions,deletions,changedFiles,files,body,labels
   

2. Full diff (for complexity and correctness analysis):

   gh pr diff <number> --repo <repo>
   

3. CI check status:

   gh pr checks <number> --repo <repo> \
     --json name,state,link,workflow,description
   

Run all commands for all PRs in parallel using the Bash tool directly (not sub-agents, which cannot inherit Bash permissions).

Step 3: Analyze each PR

For each PR, compute the following:

Review Difficulty Score (0-100, higher = easier)

Factors (weight each roughly equally):

• Size: Lines changed (additions + deletions).
  • <50 lines: 90-100
  • 50-150 lines: 60-89
  • 150-400 lines: 30-59
  • 400+ lines: 0-29
• File count: Fewer files touched = easier.
  • 1-2 files: +10 bonus
  • 10+ files: -10 penalty
• Complexity: Analyze the diff content for:
  • Mostly config/test/docs changes → easier (bonus +10)
  • New files only (no modifications) → easier (bonus +5)
  • Interleaved logic changes across many files → harder (-10)
  • Complex control flow (nested conditionals, concurrency, error handling changes) → harder (-10)

CI Status Diagnosis

Classify into one of:

• passing: All checks passed
• failing-author: Tests are failing AND the failures appear related to the code changed in the PR (e.g., same files, same feature area, test names match changed code)
• failing-flaky: Tests are failing BUT the failures appear unrelated to the PR changes (e.g., different subsystems, known flaky test patterns, infrastructure failures)
• pending: Checks are still running

If checks are failing, attempt to get failure details:

gh pr checks <number> --repo <repo> --fail-fast 2>&1

Use the check names and any available context to make the flaky vs author determination. When uncertain, say so.

Correctness Score (0-100, higher = more likely correct)

Analyze the diff for:

• Consistency: Do the changes follow existing patterns in the codebase? Are naming conventions consistent?
• Completeness: Are there obvious missing pieces? (e.g., added a function but never called it, added a route but no handler, changed behavior but no test updates)
• Edge cases: Are there obvious unhandled edge cases? (null checks, empty arrays, error paths)
• Test coverage: Did the PR include test changes that cover the new behavior?
• Description match: Does the diff match what the PR description says it does?

When uncertain, bias toward moderate scores (40-60) rather than extremes.

Step 4: Display the dashboard

Output a markdown table sorted by a combined priority score (average of difficulty and correctness, with CI failures as a tiebreaker). Easiest and most-correct PRs should appear first.

Table columns:

Priority	PR	Title	Author	Difficulty	CI	Correctness	URL

Where:

• Priority: Rank number (1 = review this first)
• Difficulty: Score with a label, e.g., 85 (easy)
  • 80-100: easy
  • 50-79: moderate
  • 0-49: hard
• CI: One of: passing, failing (author), failing (flaky), pending
• Correctness: Score with a label, e.g., 72 (likely ok)
  • 80-100: likely correct
  • 50-79: likely ok
  • 0-49: needs scrutiny

After the table, add a brief summary for each PR (2-3 sentences) explaining the key factors behind the scores. Group by priority tier:

• Quick wins (difficulty >= 80, correctness >= 70)
• Standard reviews (everything else)
• Deep dives needed (difficulty < 50 or correctness < 50)

github-review-requests.md

name	github-review-requests
description	List open PRs where your review has been requested

GitHub Review Requests

List open pull requests where your review has been requested, using the GitHub CLI.

Instructions

1. Fetch PRs needing your review:

   • Run gh search prs --review-requested=@me --state=open with the flags --json number,title,repository,url,author,createdAt
   • If this fails, check that the user has gh installed and is authenticated (gh auth status)

2. Format and display the results:

   • If no PRs are found, tell the user they have no pending review requests
   • Otherwise, display a table with columns:
     • Repo: repository.nameWithOwner
     • PR: #<number>
     • Title: title (truncated to ~60 chars if needed)
     • Author: author.login
     • URL: clickable link
   • Sort by repository name, then PR number
   • Show a count summary at the end (e.g., "5 PRs awaiting your review")