review-pr

Review PR

Uses Reviewer. Analyze a PR's diff for quality, security, and correctness. Produce structured feedback and a verdict.

Prerequisites: PR diff available (pasted or accessible), context about the PR's purpose

Phase 1: Understand Scope

Gather PR Context

1. Read PR title and description
2. Identify the issue being addressed
3. Understand the intended behavior change
4. Note the scope (files, areas affected)

Phase 2: Analyze Changes

Review Against Standards

1. Structure — Are changes organized logically?
2. Correctness — Does implementation achieve the goal?
3. Conventions — Does it follow established patterns?
4. Security — Any security implications?
5. Tests — Adequate coverage?

Review Principles

Phase 3: Provide Feedback

Structure and Present

1. Determine verdict (Approve, Request Changes, Comment)
2. List blocking issues (must fix before merge)
3. List suggestions (non-blocking improvements)
4. Note positive observations (reinforce good patterns)

Feedback Categories

Output

## Context Anchors

- **PR:** #<number> - <title>
- **Author:** <author>
- **Target:** `<branch>` → `<base>`
- **Scope:** <brief description>

## Review Summary

**Verdict:** <Approve | Request Changes | Comment>

<One paragraph summary>

## Feedback

### Blocking Issues

1. **[File:Line] <Issue title>**
   - Problem: <what's wrong>
   - Suggestion: <how to fix>

### Suggestions

1. **[File:Line] <Suggestion title>**
   - Current: <what it does now>
   - Suggested: <what would be better>

### Positive Notes

- <positive observation>

## Next Step

<If Request Changes: "Address blocking issues and re-request review">
<If Approve: "Ready to merge">
<If Comment: "Consider suggestions; no changes required">

**Approval Required:** Yes

```

### ⛔ CHECKPOINT

**STOP.** Do not post review until human explicitly approves:

- Verdict is appropriate
- Feedback is accurate
- Tone is constructive

### Board Integration

When issuing an **APPROVE** verdict and merge is confirmed in the same session:

1. Read `workspace.config.yaml` for `board.project_id`, `board.fields.status.field_id`, and `board.status_options.done.option_id`
2. Set issue status to **Done**

Only perform this update if the full approve → merge cycle completes within this review session. If merge is deferred, the Done transition belongs to Orchestrator.

---

## Mechanical Review Checklist

Before providing any review verdict, verify these mechanically:

- [ ] All changed files reviewed (none skipped)
- [ ] Build passes on the branch
- [ ] Tests pass with counts reported
- [ ] No unresolved merge conflicts
- [ ] Commit messages follow conventional format
- [ ] Branch naming follows convention
- [ ] PR description references the issue
- [ ] No `TODO` or `FIXME` markers in new code (unless tracked by issue)

---

## Error Handling

| Error                    | Recovery                                                  |
| ------------------------ | --------------------------------------------------------- |
| Missing PR context       | Request PR number or diff                                 |
| Unclear feedback         | Ask for clarification                                     |
| Conflicting requirements | Escalate to author/maintainer                             |
```