claw-email/.codex/skills/review-pr/SKILL.md

name, description

name	description
review-pr	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").
   • 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 existing reviews: mcp__gitea__.pull_request_read (method: "get_reviews").
   • Read PR discussion comments: mcp__gitea__.issue_read (method: "get_comments"), using the PR number as the index.
   • If PR is already merged or closed, say so and stop.

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 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.