/pr-review

name: pr-review
description: Reviews a GitHub pull request and posts inline comments plus one consolidated summary, adapting to any codebase by discovering the project's own test runner, requirement specs, and architecture conventions before running six specialized review agents in parallel. Stack-agnostic across language and framework; targets GitHub PRs via the gh CLI. Use when the user says "review PR 128", "review this PR", "code review this PR", or "check this pull request". Do NOT use for creating PRs or responding to review comments (use gh-address-comments), or debugging failing CI checks (use gh-fix-ci).
license: CC-BY-4.0
disable-model-invocation: true
metadata:
  author: github.com/augusto-dmh
  version: '1.0.0'

PR Review — Adaptive Orchestration Protocol

Coordinates 6 specialized subagents (via the Task tool), then consolidates their findings into one summary. This skill is **stack-agnostic**: it owns no rules of its own. Instead it discovers what the project already documents — test runner, requirement specs, architecture conventions, project-local review skills — and each subagent loads and applies **whatever that project actually has**. It never invents stack-specific rules and never duplicates project docs.

Execution Contract (NON-NEGOTIABLE)

This skill is an **orchestration-only** protocol. Read these rules before anything else:

1. You are the **orchestrator**. You MUST NOT analyze the diff, read source files, or write any review finding yourself. Your only jobs are gathering context (Step 1), launching subagents (Step 2), and spawning the consolidation subagent (Step 3). 2. The six reviews MUST run as **six separate, general-purpose subagents** (no restricted toolset), launched **in parallel in a single batch**. Use whatever subagent / parallel-task mechanism your harness provides (in Claude Code, the Task tool). 3. Doing the review inline — even partially, even "to save time", even for a small diff — is a FAILURE of this skill. There are no exceptions for diff size. 4. Each subagent prompt MUST be self-contained: it receives `{REPO}`, `{PR}`, `{SHA}`, the diff, the PR intent, the existing comment locations, and the DISCOVERY MAP. Subagents do not share your context.

**Host prerequisite:** operates on GitHub pull requests via the `gh` CLI — every fetch and post below uses `gh`. "Stack-agnostic" means language- and framework-agnostic, **not** host-agnostic: a GitLab/Bitbucket-hosted repo (which has MRs, not PRs) is out of scope.

Explicit invocation only (`disable-model-invocation: true`). Never auto-trigger during coding.

Step 1: Initialize

1a. PR context

1. Resolve PR number from the user's request; ask if absent. 2. Identify repo: `gh repo view --json nameWithOwner -q .nameWithOwner` → `{REPO}`. 3. Fetch the diff: `gh pr diff {PR}`. Get the head SHA: `gh pr view {PR} --json headRefOid -q .headRefOid` → `{SHA}` (required to anchor inline comments). 4. Load existing inline comments: `gh api repos/{REPO}/pulls/{PR}/comments` — build a set of `{id, path, line}` records: use `{path, line}` to avoid reposting, keep each body to detect now-resolved issues, and keep each `id` to post a threaded reply. 5. Read PR intent: `gh pr view {PR} --json title,body,headRefName`.

1b. Project discovery (the adaptive spine)

Probe the repo once and record a **project profile** — the DISCOVERY MAP below — passed verbatim to every subagent. Spend real effort here; it is what makes the review fit *this* project. **Prefer evidence the project states over guesses.** Detect only what exists; mark anything absent as `none`.

• **Test runner + layout** — find the command CI actually runs. Check, in order: the CI workflow (`.github/workflows/*` — or any CI config the repo keeps, e.g. `.gitlab-ci.yml`, read **only** to recover the real test command) as the **authoritative** source, then fall back to the manifest (`package.json` scripts, `pyproject.toml`/`tox.ini`/`pytest.ini`, `go.mod`, `Cargo.toml`, `Gemfile`, `Makefile`, `*.gradle`). Derive the test-file glob(s) from existing tests (e.g. `*.spec.ts`, `*_test.go`, `test_*.py`, `*_spec.rb`) and note any unit vs integration/e2e split the repo uses.
• **Requirements sources** — (A) an issue-tracker key in the branch name or PR body (e.g. `[A-Z]+-\d+` for Jira/Linear, `#\d+` or `owner/repo#\d+` for GitHub issues, full ticket URLs); (B) in-repo spec/requirement files: a `.specs/` tree, `docs/`, `*-spec.md`, `*-tasks.md`, PRD files, or ADR/RFC directories.
• **Architecture / convention docs** — whatever states the project's rules: `CONTRIBUTING*`, `ARCHITECTURE*`, `CONVENTIONS*`, `docs/**` convention files, `AGENTS.md`, `CLAUDE.md`, and any coding/integration/security pattern docs the repo keeps. Record paths; do not read them yet — the owning subagent does.
• **Project-local review skills** — scan skill dirs (`.claude/skills/`, `.cursor/skills/`, `.codex/skills/`, `.github/`) for skills covering testing, architecture/modularity, or security. Record their `SKILL.md` paths so subagents load the project's own reference instead of guessing.

Record the map compactly and pass it verbatim to every subagent:

TEST:          <command> | globs: <...> | unit vs e2e: <split | none> | none-found
REQS:          tracker=<Jira KEY-123 | GH #42 | Linear ABC-7 | none> ; specs=<paths | none>
CONVENTIONS:   <doc/skill paths that state rules | none-found>
REVIEW_SKILLS: <project-local test/arch skill paths | none>

Each subagent loads **only** what the map lists; when a category is `none`, the subagent falls back to the generic checklist in its section and says so.

Step 2: Launch subagents in parallel

Send **one message** with **six Task tool calls**, launched simultaneously. Each subagent is self-contained — it cannot see this chat, so its prompt carries the full context: `{REPO}`, `{PR}`, `{SHA}`, the diff, the existing `{id,path,line}` comment set, the PR intent, and the **project profile (the DISCOVERY MAP above)**. After