127 lines
4.5 KiB
Markdown
127 lines
4.5 KiB
Markdown
---
|
|
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 test ./...
|
|
go vet ./...
|
|
staticcheck ./...
|
|
```
|
|
- Remove worktree when done:
|
|
```
|
|
git worktree remove .worktrees/pr-<number>
|
|
```
|
|
|
|
5. **Evaluate**
|
|
- Does PR address **all** Final Requirements from the issue?
|
|
- Does PR satisfy the repo Definition of Done?
|
|
- relevant tests for behavior/config changes
|
|
- required `README.md` / `.env.example` updates
|
|
- ADR present when the change locks in a durable decision
|
|
- required implementation evidence exists on the issue and in the PR body
|
|
- 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
|
|
- staticcheck ./...: 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.
|
|
- FAIL if the PR misses required DoD evidence, docs, or ADR work for the accepted change.
|
|
- 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.
|