reviewing-prs

System skill loaded before dispatching any PR review subagent. Ensures correct file version selection based on branch and worktree state. Not invoked directly by users. Required by: code-review, advanced-code-review, distilling-prs when reviewing PRs.

5 stars

Best use case

reviewing-prs is best used when you need a repeatable AI agent workflow instead of a one-off prompt.

System skill loaded before dispatching any PR review subagent. Ensures correct file version selection based on branch and worktree state. Not invoked directly by users. Required by: code-review, advanced-code-review, distilling-prs when reviewing PRs.

Teams using reviewing-prs should expect a more consistent output, faster repeated execution, less prompt rewriting.

When to use this skill

  • You want a reusable workflow that can be run more than once with consistent structure.

When not to use this skill

  • You only need a quick one-off answer and do not need a reusable workflow.
  • You cannot install or maintain the underlying files, dependencies, or repository context.

Installation

Claude Code / Cursor / Codex

$curl -o ~/.claude/skills/reviewing-prs/SKILL.md --create-dirs "https://raw.githubusercontent.com/axiomantic/spellbook/main/skills/reviewing-prs/SKILL.md"

Manual Installation

  1. Download SKILL.md from GitHub
  2. Place it in .claude/skills/reviewing-prs/SKILL.md inside your project
  3. Restart your AI agent — it will auto-discover the skill

How reviewing-prs Compares

Feature / Agentreviewing-prsStandard Approach
Platform SupportNot specifiedLimited / Varies
Context Awareness High Baseline
Installation ComplexityUnknownN/A

Frequently Asked Questions

What does this skill do?

System skill loaded before dispatching any PR review subagent. Ensures correct file version selection based on branch and worktree state. Not invoked directly by users. Required by: code-review, advanced-code-review, distilling-prs when reviewing PRs.

Where can I find the source code?

You can find the source code on GitHub using the link provided at the top of the page.

Related Guides

SKILL.md Source

# Reviewing PRs Safely

<ROLE>
PR Review Safety Inspector. Your reputation depends on never dispatching a review subagent without first determining review_source. A review dispatched without this check produces confidently wrong verdicts — not obvious errors.
</ROLE>

## Invariant Principles

1. **Determine review_source First**: Never dispatch a PR review subagent without computing `review_source`. No exceptions.
2. **DIFF_ONLY Means No Local File Reads**: In `DIFF_ONLY` mode, local files for changed paths are on the wrong branch. Reading them produces wrong verdicts.
3. **REFUTED Requires Branch-Accurate Source**: A `REFUTED` verdict based on a local file read in `DIFF_ONLY` mode is a wrong verdict. Mark it `INCONCLUSIVE` or `[NEEDS VERIFICATION]`.
4. **Inject Review Context Into Every Subagent**: The mandatory injection block (mode, SHA, working directory, changed files) is non-optional.

## The Wrong-Branch Failure

When reviewing a PR via diff, local files are on a **different branch**. Reading them produces silently wrong results:

- PR-introduced changes appear absent (local has old code)
- Real bugs get declared "not present" → false REFUTED verdicts
- Findings carry high confidence in factually wrong conclusions

This is a structural failure: the agent reads the wrong version of the file.

## Review Source Decision

<analysis>
Before dispatching any review subagent, determine which mode applies:
1. Is there a worktree checked out to the PR branch?
2. Is the local HEAD already at the PR HEAD SHA?
3. If neither, the agent is on the wrong branch — DIFF_ONLY mode applies.
</analysis>

Before dispatching any code review subagent, determine `review_source`:

```bash
PR_HEAD_SHA=$(gh pr view <PR_NUMBER> --json headRefOid --jq '.headRefOid')
LOCAL_HEAD=$(git rev-parse HEAD)
PR_BRANCH=$(gh pr view <PR_NUMBER> --json headRefName --jq '.headRefName')
WORKTREE_PATH=$(git worktree list --porcelain | grep -B1 "branch refs/heads/$PR_BRANCH" | grep "^worktree" | awk '{print $2}')
```

| Condition | `review_source` | Working Directory |
|-----------|-----------------|-------------------|
| `$WORKTREE_PATH` is set | `LOCAL_FILES` | `$WORKTREE_PATH` |
| `$LOCAL_HEAD == $PR_HEAD_SHA` | `LOCAL_FILES` | Current repo root |
| Neither | `DIFF_ONLY` | N/A |

## What Each Mode Means

### `LOCAL_FILES` mode

The agent works in a directory that **is** the PR branch. File reads are authoritative.

- Safe to read changed files
- Safe to verify/refute findings by reading line content
- **MUST specify the working directory** — the agent must not stray outside it

### `DIFF_ONLY` mode

No local checkout matches the PR. The diff is the only source of truth.

- **NEVER read local files from the changed file set**
- All verification functions return `INCONCLUSIVE` (not `REFUTED`)
- Findings that cannot be verified from the diff are marked `[NEEDS VERIFICATION]`
- A finding marked `REFUTED` based on a local file read is a **wrong verdict**

## Mandatory Injection

Every subagent dispatched to review a PR **must** receive this context block:

```markdown
## PR Review Context

- PR: #<NUMBER>
- PR HEAD SHA: <SHA>
- Review mode: <LOCAL_FILES | DIFF_ONLY>
- Working directory: <path if LOCAL_FILES, "N/A — use diff only" if DIFF_ONLY>
- Changed files: <list>

If review mode is DIFF_ONLY:
  - Do NOT read any files listed under "Changed files" from the local filesystem
  - The diff is the only authoritative source for those files
  - Mark any finding you cannot verify from the diff as [NEEDS VERIFICATION]
  - Do NOT mark a finding REFUTED based on local file content
```

## Why Worktrees Are the Clean Solution

Checking out a PR branch in a worktree converts a `DIFF_ONLY` review into a `LOCAL_FILES` review. The agent gets safe, branch-accurate file reads without polluting the main working tree.

```bash
# Check out PR branch in a worktree
git worktree add ~/.local/worktrees/pr-<NUMBER> <PR_BRANCH>
```

Once the worktree exists, dispatch the review agent with `working_directory: ~/.local/worktrees/pr-<NUMBER>`.

## Self-Check

<reflection>
Before dispatching any PR review subagent:
- Was review_source determined before anything else?
- Does the subagent prompt include the mandatory injection block?
- If DIFF_ONLY: does the prompt explicitly prohibit local file reads on changed files?
</reflection>

Before dispatching any PR review subagent:

- [ ] `PR_HEAD_SHA` fetched from GitHub (not guessed)
- [ ] `review_source` determined: `LOCAL_FILES` or `DIFF_ONLY`
- [ ] If `LOCAL_FILES`: exact working directory specified in prompt
- [ ] If `DIFF_ONLY`: prompt explicitly forbids local file reads on changed files
- [ ] Changed file list included so agent knows what is "in scope"

<FORBIDDEN>
- Dispatching a PR review subagent without computing `review_source` first
- Allowing the agent to default to reading local files when `review_source == DIFF_ONLY`
- Treating a `REFUTED` verdict from a local file read as valid in `DIFF_ONLY` mode
- Skipping the worktree check — a worktree converts a lossy review into an accurate one
</FORBIDDEN>

<FINAL_EMPHASIS>
The wrong-branch problem produces confident wrong answers, not obvious errors. An agent that reads the wrong version of a file will declare "this bug does not exist" with full conviction. The only defense is checking the review source before dispatch — every time.
</FINAL_EMPHASIS>

Related Skills

reviewing-impl-plans

5
from axiomantic/spellbook

Use when reviewing implementation plans before execution. Triggers: 'is this plan solid', 'review the plan', 'check before I start building', 'anything missing from this plan', 'will this plan work', 'audit the implementation plan'. NOT for: reviewing design documents (use reviewing-design-docs) or creating plans (use writing-plans).

reviewing-design-docs

5
from axiomantic/spellbook

Use when reviewing design documents, technical specifications, architecture docs, RFCs, ADRs, or API designs for completeness and implementability. Triggers: 'review this design', 'is this spec complete', 'can someone implement from this', 'what's missing from this design', 'review this RFC', 'is this ready for implementation', 'audit this spec'. Core question: could an implementer code against this without guessing?

writing-skills

5
from axiomantic/spellbook

Use when creating new skills, editing existing skills, or verifying skills work before deployment. Triggers: 'write a skill', 'new skill', 'create a skill', 'skill doesn't work', 'skill isn't firing', 'edit skill', 'skill quality'. NOT for: general prompt improvement (use instruction-engineering) or command creation (use writing-commands).

writing-plans

5
from axiomantic/spellbook

Use when you have a spec, design doc, or requirements and need a detailed implementation plan before coding. Triggers: 'write a plan', 'create implementation plan', 'plan this out', 'break this down into steps', 'convert design to tasks', 'implementation order'. Also invoked by develop during planning. NOT for: reviewing existing plans (use reviewing-impl-plans).

writing-commands

5
from axiomantic/spellbook

Use when creating new commands, editing existing commands, or reviewing command quality. Triggers: 'write command', 'new command', 'create a command', 'review command', 'fix command', 'command doesn't work', 'add a slash command'. NOT for: skill creation (use writing-skills).

verifying-hunches

5
from axiomantic/spellbook

Use when about to claim discovery during debugging. Triggers: "I found", "this is the issue", "I think I see", "looks like the problem", "that's why", "the bug is", "root cause", "culprit", "smoking gun", "aha", "got it", "here's what's happening", "the reason is", "causing the", "explains why", "mystery solved", "figured it out", "the fix is", "should fix", "this will fix". Also invoked by debugging, scientific-debugging, systematic-debugging before any root cause claim.

using-skills

5
from axiomantic/spellbook

System skill loaded at session start to initialize skill routing. Not invoked directly by users. Also useful when: 'which skill should I use', 'what skill handles this', 'wrong skill fired', 'skill didn't trigger'.

using-lsp-tools

5
from axiomantic/spellbook

Use when mcp-language-server tools are available and you need semantic code intelligence. Triggers: 'find definition', 'find references', 'who calls this', 'rename symbol', 'type hierarchy', 'go to definition', 'where is this used', 'where is this defined', 'what type is this'. Provides navigation, refactoring, and type analysis via LSP.

using-git-worktrees

5
from axiomantic/spellbook

Use when starting feature work that needs isolation from current workspace, or setting up parallel development tracks. Triggers: 'worktree', 'separate branch', 'isolate this work', 'don't mess up current work', 'work on two things at once', 'parallel workstreams', 'new branch for this', 'keep my current work safe'.

tooling-discovery

5
from axiomantic/spellbook

Use when looking for available tools, MCP servers, or CLI utilities for a task. Triggers: 'what tools do I have', 'is there an MCP for this', 'what's available', 'find a tool for', 'discover tooling', 'what CLI tools exist'. NOT for: documenting existing tools (use documenting-tools).

testing-strategy

5
from axiomantic/spellbook

Test selection strategy and scope guidance. Triggers: 'which tests should I run', 'test tiers', 'test marks', 'slow tests', 'integration vs unit', 'cross-module regression', 'test scope', 'what should I run', 'select tests', 'test batching'. NOT for: writing tests (use test-driven-development) or fixing broken tests (use fixing-tests).

test-driven-development

5
from axiomantic/spellbook

Use when user explicitly requests test-driven development. Triggers: 'TDD', 'write tests first', 'red green refactor', 'test-first', 'start with the test'. Also invoked by develop and executing-plans for implementation tasks. NOT for: full feature work (use develop, which includes TDD internally).