review-pr

# Review PR Comments

Fetch, evaluate, and address PR review comments from GitHub. Many reviewer comments reference outdated code or misunderstand the logic — always verify against the actual codebase before acting.

## Process

**This is a single-pass flow.** Fetch comments, read files, evaluate, present assessment, reply to all comments, resolve all threads, and show the final summary — all without pausing for user confirmation.

### 1. Find the PR

If no PR number is provided, find the PR for the current branch:

```bash
gh pr list --head $(git branch --show-current) --json number,title --jq '.[0]'
```

### 2. Fetch Review Comments

Fetch comments with their IDs:

```bash
gh api repos/{owner}/{repo}/pulls/{number}/comments --jq '.[] | {id: .id, path: .path, line: (.line // .original_line), body: .body, in_reply_to_id: .in_reply_to_id}'
```

Filter to only top-level comments (where `in_reply_to_id` is null).

### 3. Read Referenced Files (Critical Step)

**Before evaluating any comment, read the actual current code.** Reviewers often:
- Reference line numbers from an older commit
- Misread the logic
- Comment on code that's already been fixed

For each unique file path, read the file and verify:
- Does the line number match what the reviewer is describing?
- Has the issue already been addressed?
- Is the reviewer's understanding of the code correct?

### 4. Evaluate All Comments

Categorize each comment:

| Category | Criteria | Response |
|----------|----------|----------|
| **Already addressed** | Issue was fixed in a subsequent commit, or reviewer misread the code | Explain what the code actually does |
| **Fix** | Valid bug, security issue, or typo that exists in current code | Implement the fix |
| **Won't fix** | Over-engineering, style preference, feature request, or would break consistency | Explain reasoning |

### 5. Present Assessment, Reply, and Resolve

**Do all of this in one pass — no pausing for user confirmation.** Present your assessment, reply t