---
name: review-pr
description: Phase 2 skill. Use when a PR is created or updated. Review PR against locked issue requirements and post verdict as Reviewer. Do NOT edit code on the PR.
---

# Review PR

**Phase:** 2 — Requirement Implementation
**Role:** Reviewer

## When to invoke

- User says: "review PR #X", "check PR #X", "/review-pr #X"
- A PR is created or updated and needs review.

## Prerequisite

- PR exists on Gitea.
- The referenced issue has a **Final Requirements** comment from PO (Phase 1 done).

## Workflow

1. **Load PR and issue**
   - Read PR: `mcp__gitea__.pull_request_read` (`method: "get"`).
   - If PR is already merged or closed, say so and stop.
   - Read current Gitea user: `mcp__gitea__.get_me`.
   - Read existing reviews: `mcp__gitea__.pull_request_read` (`method: "get_reviews"`).
   - If the current user is not already requested as a reviewer and has not already reviewed this PR, add them with `mcp__gitea__.pull_request_write` (`method: "add_reviewers"`).
   - Identify the linked issue from PR body (`Fixes #<id>` or `Closes #<id>`).
   - Read issue comments, find the **Final Requirements** comment: `mcp__gitea__.issue_read` (`method: "get_comments"`).
   - Read PR discussion comments: `mcp__gitea__.issue_read` (`method: "get_comments"`), using the PR number as the index.

2. **Read review history** (for re-reviews)
   - Get review comments: `mcp__gitea__.pull_request_read` (`method: "get_review_comments"`).
   - Treat reviews, inline review comments, and PR discussion comments as separate context sources.
   - If author addressed feedback in a follow-up commit, focus on new commits but still sanity-check the full diff.

3. **Get the diff**
   - Use `mcp__gitea__.pull_request_read` (`method: "get_diff"`).
   - Use `mcp__gitea__.get_file_contents` for surrounding context when needed.

4. **Validate locally** (when needed)
   - Create worktree:
     ```
     git worktree add .worktrees/pr-<number> origin/<head-branch>
     ```
   - Run checks:
     ```
     gofmt -l .
     go vet ./...
     go test ./...
     ```
   - Remove worktree when done:
     ```
     git worktree remove .worktrees/pr-<number>
     ```

5. **Evaluate**
   - Does PR address **all** Final Requirements from the issue?
   - Does PR contain unrelated changes or refactoring? → FAIL immediately.
   - Code correctness, style, test coverage.

6. **Write verdict**
   - Start with **PASS** or **FAIL**.
   - Include file:line references for findings.
   - Explain concrete impact, not style preferences.

7. **Post review**
   - Post proactively if verdict is clear.
   - Use `mcp__gitea__.pull_request_review_write` (`method: "create"`):
     - `PASS` → `state: "APPROVED"`
     - `FAIL` → `state: "REQUEST_CHANGES"`
     - Non-blocking note → `state: "COMMENT"`
   - For plain discussion (not changing review state): `mcp__gitea__.issue_write` (`method: "add_comment"`).

## Review Format

### PASS
```
PASS

No blocking issues found.

Validation:
- gofmt -l .: OK
- go vet ./...: OK
- go test ./...: OK

Non-blocking:
- <optional note>
```

### FAIL
```
FAIL

1. [High] <issue with path:line and impact>
2. [Medium] <issue with path:line and impact>

Validation:
- go test ./...: FAIL (<details>)
```

## Rules
- Use Gitea MCP tools for all PR/review operations.
- Do not add yourself as reviewer twice; check requested reviewers and existing reviews first.
- Do NOT edit code on the PR.
- FAIL if PR contains unrelated changes or scope creep.
- Post review proactively if verdict is clear.
- Do not post a verdict until PR discussion comments have been checked.
- Mention validation commands you actually ran.
- No bracketed author/tool tags.
- Accept `docs/adr/**` when it records a direct, durable decision tied to the issue scope.
- Treat `docs/superpowers/**` and other agent execution artifacts as scope creep. When rejecting docs, explain whether the content should be deleted entirely or rewritten as an ADR.

## What happens next
- **PASS (APPROVED):** Developer merges the PR.
- **FAIL (REQUEST_CHANGES):** Developer fixes feedback, then user re-invokes `/review-pr` on this PR.