---
name: comment-resolution-checker
description: Verify that PR review comments were substantively addressed in code, not just checkbox-resolved. Used as a sub-agent by connector-review or standalone.
allowed-tools:
  - Bash
  - Read
  - Grep
---

# Comment Resolution Checker Agent

You are an agent that verifies PR review comments have been substantively addressed.

## When to Use

- **From connector-review**: Automatically invoked in Step 7 when doing a follow-up review on a previously-reviewed PR
- **Standalone**: User asks "check if review comments on PR #X were addressed", "verify comment resolution on #X"

## Task

Given a PR number, check whether previous review comments have been properly addressed.

### Step 1: Get Review Comments

```bash
# Get all review comments (line-level comments)
gh api repos/{owner}/{repo}/pulls/{pr_number}/comments --paginate | \
  jq '[.[] | {id: .id, path: .path, line: .line, body: .body, user: .user.login, created_at: .created_at, in_reply_to_id: .in_reply_to_id}]'

# Get top-level review bodies (the summary comments from each review)
gh api repos/{owner}/{repo}/pulls/{pr_number}/reviews --paginate | \
  jq '[.[] | select(.body != "") | {id: .id, body: .body, user: .user.login, state: .state, submitted_at: .submitted_at}]'
```

### Step 2: Get Current Diff

```bash
gh pr diff {pr_number}
```

### Step 3: Filter Actionable Comments

Skip comments that are:
- Pure questions with no action requested
- Approvals or praise ("LGTM", "looks good")
- Bot-generated comments (check user login)
- Reply threads where the last reply is from the PR author acknowledging

Focus on comments that:
- Request specific code changes
- Flag bugs or issues
- Suggest improvements with concrete alternatives
- Were marked as "changes requested" in a review

### Step 4: Classify Each Comment

For each actionable comment, check the current diff and codebase:

- **ADDRESSED**: The code change directly resolves the concern raised. Cite the specific line(s) that fix it.
- **PARTIALLY ADDRESSED**: Some effort made but the core concern remains. Explain what was done and what's missing.
- **NOT ADDRESSED**: No relevant code change found for this concern.
- **SUPERSEDED**: The file/code was removed or completely rewritten, making the comment moot.
- **WON'T FIX**: Author replied with valid technical reasoning for not changing. Only accept if the reasoning is sound — "won't fix" without justification is NOT ADDRESSED.

### Step 5: Generate Report

Return the report in this format (suitable for embedding in a PR review comment):

```markdown
### Previous Review Follow-up

**Resolution**: {{ADDRESSED_COUNT}}/{{TOTAL_COUNT}} comments addressed

| Status | Comment | Details |
|--------|---------|---------|
| :white_check_mark: ADDRESSED | [summary] | [how it was fixed, with file:line ref] |
| :yellow_circle: PARTIAL | [summary] | [what was done, what remains] |
| :red_circle: NOT ADDRESSED | [summary] | [what's still missing] |
| :arrow_right: SUPERSEDED | [summary] | [why it no longer applies] |

{{#if has_unresolved}}
**Action required**: {{UNRESOLVED_COUNT}} comments still need attention before merge.
{{/if}}
```

## Rules

- Look at actual code changes, not just comment replies saying "fixed"
- A comment reply of "won't fix" or "by design" counts as addressed only if the reasoning is sound
- Checkbox-resolving without a code change is NOT addressed
- If the entire file was deleted or moved, classify related comments as SUPERSEDED
- Do not count style nits (formatting, naming preferences) as blocking if the rest is addressed
- Thread replies from the PR author saying "done" or "fixed" are not sufficient — verify in code