/pr-reviewer

name: pr-reviewer
description: "Review pull requests with full context. Fetches linked Jira tickets, Figma designs, and Notion docs via MCP, spawns parallel subagents for systematic code review (correctness, security, tests, SOLID, clean code), then drafts friendly, humanized GitHub-ready comments. Use when reviewing PRs, examining code changes, or when the user asks for a code review."

PR Reviewer

> **No em-dashes.** Nothing this skill writes may contain an em-dash; use a comma, colon, or parentheses instead. Enforced by a repo hook that flags em-dashes in generated `.md`. See `/flagrare:write-docs`.

Reviews pull requests systematically with full context awareness and humanized feedback.

This skill fetches linked resources via MCP, spawns parallel review subagents for systematic analysis, then synthesises findings into friendly, GitHub-ready comment drafts.

---

When to Use

• User asks to review a PR, code changes, or diff
• User shares a PR link or number
• User asks "review this", "what do you think of these changes", "check this PR"
• User provides a GitHub PR URL

---

Workflow

Step 1: Identify the PR

Parse the PR from user input:

• GitHub URL: extract owner, repo, PR number
• PR number: use current repo context
• Branch name: find associated PR via `gh pr list`

Fetch the PR details:

gh pr view <number> --json title,body,files,commits,labels,baseRefName,headRefName
gh pr diff <number>

Step 2: Extract and Fetch Linked Resources via MCP

Scan the PR title, description, branch name, and commit messages for linked resources.

**Jira/Atlassian tickets:**

Extract ticket IDs matching `[A-Z]+-[0-9]+` (e.g. `SKU-123`, `CORE-3211`).

1. Call `getAccessibleAtlassianResources` to obtain `cloudId` 2. For each ticket key, call `getJiraIssue` with `cloudId` and `issueIdOrKey` 3. Use the ticket's summary, description, and acceptance criteria to verify alignment

**Figma links:**

Extract URLs matching `figma.com/design/:fileKey/:fileName?node-id=...`

1. Parse `fileKey` and `nodeId` (convert `-` to `:` in node-id) 2. Call `get_design_context` with `fileKey` and `nodeId` 3. Optionally call `get_screenshot` for visual reference

**Notion docs:**

Extract URLs matching `*.notion.so/...` or `*.notion.site/...`

1. Call the Notion MCP to fetch page content 2. Use for requirements, API specs, or architecture decisions

**If MCP fails:**

Note it in the review: "Could not fetch Jira ticket CORE-3211 (Atlassian MCP unavailable). Review based on PR description only." Proceed with available context.

Step 3: Systematic Code Review (parallel subagents)

Spawn **five review subagents in parallel** using `model: "sonnet"`. Each receives the full PR diff and returns findings.

Do not run these checks sequentially. Spawn all five simultaneously, collect results, then synthesise.

**Rules every brief below inherits.** Paste these into each subagent's prompt ahead of its brief. The coverage, scope and evidence rules here, and the evidenced-drop rule in Step 5, are adapted from the review prompts in alibaba/open-code-review; the teardown is at [`docs/research/2026-09-14-open-code-review-teardown.md`](../../../../docs/research/2026-09-14-open-code-review-teardown.md).

• **Report your coverage.** Open your report with one line: files seen, files reviewed, files skipped with a one-phrase reason each. A file whose hunks you did not read is skipped, not reviewed. Reviewing an implementation file does not cover its interface, its config, its type declarations, or its barrel export; the secondary file is where contract drift hides, and it is the one most often skipped.
• **Reading is unbounded, findings are not.** Read whatever you need to understand the change, including files outside the diff. File findings only against code inside the diff. A problem on a line the author did not touch is context you gathered, not a finding.
• **Spend your calls on evidence, not on certainty.** Budget roughly two or three tool calls per finding. Once you can cite the construct and say what is wrong with it, write the finding and move on; the main agent verifies every finding after you report it. Never call the same tool twice with the same arguments.
• **Finding nothing is a result.** If a sweep turns up nothing real, say so and finish. Do not keep probing for marginal findings, and do not manufacture one to prove you read the diff; your coverage line is that proof. An invented finding costs more than a missed one, because it trains the reader to skim the whole report.
• **Every finding cites its construct.** File, line, and the code you are talking about. A finding without a citation is a hunch, and hunches do not leave the subagent.

---

Subagent 1: Correctness & Logic

**Inputs:** full PR diff, PR description, linked ticket acceptance criteria.

For every changed function/method:

• Does the logic match the stated intent (from PR description and ticket)?
• Are there off-by-one errors, missing null checks, unhandled branches?
• Are edge cases covered: empty input, boundary values, error paths?
• Are there race conditions or ordering assumptions?
• Does the change break any existing callers?

---

Subagent 2: Security

**Inputs:** full PR diff, file list.

Scan for OWASP Top 10 patterns:

• Injection (SQL, command, XSS, template)
• Broken authentication / authorization checks
• Sensitive data exposure (logging secrets, hardcoded keys)
• Missing input validation at system boundaries
• Insecure deserialization
• Overly permissive CORS or CSP
• Dependencies with known vulnerabilities (if lockfile changed)

Only flag issues with concrete exploit paths, not theoretical risks.

---

Subagent 3: Test Coverage & Quality

**Inputs:** full PR diff (test files and non-test files).

For every behavior introduced or changed:

• Is there at least one test that exercises it through the public API?
• Do tests assert on observable behavior or implementation internals?
• Are test names desc