/pr-review

name: pr-review
description: Reviews pull requests with scope validation, requirements compliance, and line comments. Use when reviewing GitHub or GitLab PRs.
alwaysApply: false
category: review
tags:
- pr
- review
- scope
- github
- gitlab
- code-quality
- knowledge-capture
- cross-platform
tools: []
usage_patterns:
- scope-validation
- backlog-triage
- requirement-compliance
- knowledge-capture
complexity: intermediate
estimated_tokens: 500
progressive_loading: true
modules:
- modules/anti-patterns.md
- modules/comment-guidelines.md
- modules/educational-insights.md
- modules/github-comments.md
- modules/insight-generation.md
- modules/interactive-review.md
- modules/knowledge-capture.md
- modules/pr-hygiene.md
- modules/suggestion-comments.md
- modules/version-validation.md
- modules/scope-classification.md
- modules/slop-detection.md
dependencies:
- leyline:git-platform
- sanctum:git-workspace-review
- sanctum:version-updates
- pensive:unified-review
- imbue:proof-of-work
- imbue:justify
- imbue:review-core
- imbue:structured-output
- memory-palace:review-chamber
- scribe:slop-detector
- scribe:doc-generator
role: entrypoint

Scope-Focused PR Review

Review pull/merge requests with discipline: validate against original requirements, prevent scope creep, and route out-of-scope findings to issues on the detected platform.

**Platform detection is automatic** via `leyline:git-platform`. Use `gh` for GitHub, `glab` for GitLab. Check session context for `git_platform:`.

Core Principle

**A PR review validates scope compliance, not code perfection.**

The goal is to validate the implementation meets its stated requirements without introducing regressions. Improvements beyond the scope belong in future PRs.

When To Use

• Before merging any feature branch
• When reviewing PRs from teammates
• To validate your own work before requesting review
• To generate a backlog of improvements discovered during review

When NOT To Use

• Preparing PRs - use pr-prep instead
• Deep code

review - use pensive:unified-review

• Preparing PRs - use pr-prep instead
• Deep code

review - use pensive:unified-review

Scope Classification Framework

How each finding is classified against the PR's stated scope: [`modules/scope-classification.md`](modules/scope-classification.md).

Workflow

Phase 1: Establish Scope Baseline

Before looking at ANY code, understand what this PR is supposed to accomplish.

**Note:** Version validation (Phase 1.5) runs AFTER scope establishment but BEFORE code review. See `modules/version-validation.md` for details.

**Search for scope artifacts in order:**

1. **Plan file**: Most authoritative (check spec-kit locations first, then root)

   # Spec-kit feature plans (preferred - structured implementation blueprints)
   find specs -name "plan.md" -type f 2>/dev/null | head -1 | xargs cat 2>/dev/null | head -100
   # Legacy/alternative locations
   ls docs/plans/ 2>/dev/null
   # Root plan.md (may be Claude Plan Mode artifact from v2.0.51+)
   cat plan.md 2>/dev/null | head -100

**Verification:** Run the command with `--help` flag to verify availability.

2. **Spec file**: Requirements definition (check spec-kit locations first)

   find specs -name "spec.md" -type f 2>/dev/null | head -1 | xargs cat 2>/dev/null | head -100
   cat spec.md 2>/dev/null | head -100

**Verification:** Run the command with `--help` flag to verify availability.

3. **Tasks file**: Implementation checklist (check spec-kit locations first)

   find specs -name "tasks.md" -type f 2>/dev/null | head -1 | xargs cat 2>/dev/null
   cat tasks.md 2>/dev/null

**Verification:** Run the command with `--help` flag to verify availability.

4. **PR/MR description**: Author's intent

   # GitHub
   gh pr view <number> --json body --jq '.body'
   # GitLab
   glab mr view <number> --json description --jq '.description'

**Verification:** Run the command with `--help` flag to verify availability.

5. **Commit messages**: Incremental decisions

   # GitHub
   gh pr view <number> --json commits --jq '.commits[].messageHeadline'
   # GitLab
   glab mr view <number> --json commits

**Verification:** Run the command with `--help` flag to verify availability.

**Output:** A clear statement of scope: > "This PR implements [feature X] as specified in plan.md. The requirements are: > 1. [requirement] > 2. [requirement] > 3. [requirement]"

If no scope artifacts exist, flag this as a process issue but continue with PR description as the baseline.

Phase 2: Gather Changes

# GitHub
gh pr diff <number> --name-only
gh pr diff <number>
gh pr view <number> --json additions,deletions,changedFiles,commits

# GitLab
glab mr diff <number>
glab mr view <number>

**Verification:** Run the command with `--help` flag to verify availability.

Phase 3: Requirements Validation

Before detailed code review, check scope coverage:

• [ ] Each requirement has corresponding implementation
• [ ] No requirements are missing
• [ ] Implementation doesn't exceed requirements (overengineering signal)

Phase 1.5: Version Validation (MANDATORY)

**Run version validation checks BEFORE code review.**

See `modules/version-validation.md` for detailed validation procedures.

**Quick reference:** 1. Check if bypass requested (`--skip-version-check`, label, or PR marker) 2. Detect if version files changed in PR diff 3. If changed, run project-specific validations:

• Claude marketplace: Check marketplace.json vs plugin.json versions
• Python: Check pyproject.toml vs __version__
• Node: Check package.json vs package-lock.json
• Rust: Check Cargo.toml vs Cargo.lock

4. Validate CHANGELOG has entry for new version 5. Check README/docs for version references 6. Classify findings as BLOCKING (or WAIVED if bypassed)

**All version mismatches are BLOCKING unless explicitly waived by maintainer.**

Phase 3.5: PR Hyg