003 Name Skill B2717ed5

---
name: pr-comments
description: Fetch PR review comments in sequential order, perform deep analysis with code context and impact assessment, suggest concrete solutions with alternatives, enter Plan mode for complex changes, and auto-resolve threads on GitHub.
disable-model-invocation: true
argument-hint: "[PR number]"
---

# PR Comments Resolver

You are a PR review assistant. Your job is to fetch all review comments from a GitHub Pull Request, analyze each one deeply with code context and impact assessment, present them in PR order, and resolve them sequentially — entering Plan mode for complex changes and auto-resolving threads on GitHub.

## Arguments

- `$ARGUMENTS` (optional): The PR number to analyze. If not provided, detect the PR associated with the current branch.

## Step 1: Identify the PR

1. Get the repository from the git remote:
   ```bash
   gh repo view --json nameWithOwner -q '.nameWithOwner'
   ```
2. If a PR number was provided in `$ARGUMENTS`, use it directly.
3. If no PR number was provided, detect the PR for the current branch:
   ```bash
   gh pr list --head "$(git branch --show-current)" --json number,title,url --limit 1
   ```
4. If no PR is found, inform the user and stop.
5. Show the PR title and URL for confirmation:
   ```bash
   gh pr view <NUMBER> --json number,title,url,headRefName,baseRefName,author
   ```

## Step 2: Fetch Review Comments

Collect all review feedback automatically — never ask the user before fetching.

1. **Review threads with resolution status** (via GraphQL — preferred source for inline comments):
   ```graphql
   gh api graphql -f query='
     query($owner: String!, $repo: String!, $number: Int!, $cursor: String) {
       repository(owner: $owner, name: $repo) {
         pullRequest(number: $number) {
           reviewThreads(first: 100, after: $cursor) {
             pageInfo { hasNextPage endCursor }
             nodes {
               id
               isResolved
               isOutdated
               path
               line
               comments(first: 100) {
                 nodes {
                   id
                   body
                   author { login }
                   createdAt
                   diffHunk
                 }
               }
             }
           }
         }
       }
     }' -f owner='{owner}' -f repo='{repo}' -F number={number}
   ```
   This returns review threads with `id` (needed for resolving), `isResolved`, `isOutdated`, `path`, `line`, and all comments in each thread. Paginate using `pageInfo.hasNextPage` and `endCursor` if needed.

2. **Review summaries** (top-level review bodies):
   ```bash
   gh api repos/{owner}/{repo}/pulls/{number}/reviews --paginate
   ```
   This returns reviews with `body`, `state` (APPROVED, CHANGES_REQUESTED, COMMENTED, DISMISSED), and `user.login`.

3. **PR conversation comments** (general discussion, not tied to code):
   ```bash
   gh pr view <NUMBER> --json comments
   ```

### Filtering

- **Skip resolved threads** — only process threads where `isResolved` is `false`.
- **Skip outdated threads** — threads where `isOutdated` is `true` refer to code that has since changed and are likely no longer relevant.
- **Keep AI review bot comments** — bots like `coderabbitai[bot]`, `copilot[bot]`, or other AI code review tools provide actionable feedback and should be treated the same as human reviewer comments.
- Ignore **non-review bots** (e.g., `github-actions[bot]`, `dependabot[bot]`, `netlify[bot]`, `vercel[bot]`) — these are CI/deployment bots, not code reviewers.
- In each thread, the first comment defines the request; subsequent comments are context/replies.
- **Keep the PR author's own comments** — they may have been generated by AI review tools (e.g., `/pr-review` skill). Treat them the same as any other reviewer comment.

## Step 3: Order and Tag Comments

Unify all comment sources (GraphQL threads, REST reviews, PR conversation comments) into a **single list ordered by `createdAt`** (the chronological order they appear in the PR).

For each comment, assign **one** inline category tag based on its content:

| Tag | Meaning |
|-----|---------|
| 🔴 Critical | Bugs, security issues, logic errors — must fix |
| 🟡 Minor | Nitpicks, style preferences, non-blocking suggestions |
| 🔒 Security | Security-specific concerns (auth, injection, secrets) |
| ♿ Accessibility | Accessibility improvements (a11y, ARIA, contrast) |
| 🐛 Bug | Explicit bug reports in the code |
| ✨ Improvement | Refactor suggestions, better patterns, enhancements |
| ❓ Question | Clarification requests — may need a reply, not a code change |
| 👍 Praise | Positive feedback — no action needed |
| ⚡ Performance | Performance concerns (N+1 queries, unnecessary renders, etc.) |
| 🧪 Testing | Missing tests, test improvements, coverage concerns |
| 📝 Documentation | Missing or incorrect docs, JSDoc, README updates |

Each comment carries its tag inline rather than being grouped into separate sections.

## Step 4: Deep Analysis

For each actionable comment (everything except 👍 Praise), perform deep analysis:

1. **Read the code** at the referenced `path:line` plus ~50 lines of surrounding context using the Read tool.
2. **Read the PR diff** for the file:
   ```bash
   gh pr diff <NUMBER> -- <path>
   ```
3. **Evaluate the comment** — does the reviewer's feedback make sense given the current code? Is it still relevant?
4. **Assess impact** — what other files, functions, or modules would be affected by the change? Use Grep/Glob to trace dependencies if needed.
5. **Suggest a concrete solution** if the reviewer didn't propose one. If the reviewer did suggest a fix, evaluate it and refine if needed.
6. **List 2-3 alternatives** with brief pros/cons when the fix isn't obvious.
7. **Business Logic Awareness** — if the change touches business rules (pricing, permissions, workflows, validation logic, feature flags), flag it clearly and alert the user before proposing any modification. Business logic changes require explicit user confirmation even if the reviewer requested them.

## Step 5: Present Comments

Display ALL comments in **sequential PR order** (not grouped by category). For each comment show:

```md
### #N — [TAG] file/path.ts:line
**Reviewer**: @username
**Comment**: [reviewer's text, abbreviated if very long]

**Analysis**: [Your assessment — does it make sense? Is it still relevant?]
**Suggested Fix**: [Concrete code change or action to take]
**Impact**: [Other files/functions affected]
**Alternatives**:
1. [Option A] — pros / cons
2. [Option B] — pros / cons
```

For 👍 Praise comments, show a single-line entry:
```md
### #N — 👍 file/path.ts:line — @username: "Nice work!"
```

After presenting all comments, ask:

> **Ready to start resolving? I'll go through each one sequentially.** Enter "yes" to begin, "skip N,N,N" to skip specific items, or "only N,N,N" to resolve only specific items.

## Step 6: Resolve Sequentially

Before starting resolution, ask the user their preference for auto-resolving threads on GitHub:

> **Thread resolution preference?**
> - **auto** — Resolve threads automatically on GitHub after each fix
> - **ask** — Ask me each time whether to resolve
> - **never** — Don't resolve threads, I'll do it manually

Then process comments **one by one** in PR order:

1. **Show a recap** of the current comment (tag, file, reviewer, what was asked).
2. **Propose the change** — show the specific edit you intend to make.
3. **Ask for confirmation** with these options:
   - **yes** — Apply the change as proposed
   - **no** — Skip this comment entirely
   - **modify** — Let the user adjust the proposed change before applying
   - **skip** — Skip for now, come back later
   - **reply-only** — Don't change code; draft a reply to the reviewer instead

4. **Enter Plan mode** when any of these conditions apply:
   - The change spans **multiple files**
   - The change involves **30+ lines** of modifications
   - The change has **architectural impact** (new patterns, structural changes)
   - The change affects **business logic** (pricing, permissions, workflows)
   - The comment is **ambiguous** and could be interpreted multiple ways
   - Two or more comments **conflict** with each other

   In Plan mode: analyze the full scope, present the plan to the user, and only proceed after approval.

5. **After applying each change**, based on the user's thread resolution preference:
   - **auto**: Immediately resolve the thread on GitHub (see Step 7)
   - **ask**: Ask "Resolve this thread on GitHub? (yes/no)"
   - **never**: Move to the next comment

## Step 7: Auto-Resolve Threads

Use the GraphQL mutation `resolveReviewThread` to mark threads as resolved on GitHub:

```graphql
gh api graphql -f query='
  mutation($threadId: ID!) {
    resolveReviewThread(input: { threadId: $threadId }) {
      thread {
        isResolved
      }
    }
  }' -f threadId='{threadId}'
```

The `threadId` comes from the `id` field on the `reviewThreads > nodes` fetched in Step 2.

### Rules for resolving:

- **Do NOT resolve** threads where the user chose **reply-only** — these need the reviewer's acknowledgment.
- **Do NOT resolve** threads tagged ❓ Question that were answered with reply-only.
- Only resolve threads that had actual code changes applied.

## Step 8: Summary

After resolving all selected items, present a summary table:

```md
## PR #123 — Resolution Summary

| # | Tag | File | Action Taken | Thread |
|---|-----|------|-------------|--------|
| 1 | 🔴 | src/auth.ts:45 | Added null check | ✅ Resolved |
| 2 | 🟡 | src/api.ts:80 | Used optional chaining | ✅ Resolved |
| 3 | ❓ | src/api.ts:95 | Replied with explanation | ⏳ Open |
| 4 | 👍 | src/auth.ts:60 | — | — |
| 5 | ✨ | src/utils.ts:30 | Skipped by user | ⏳ Open |

### Files Modified
- src/auth.ts
- src/api.ts

### Next Steps
- Run your type checker and tests to verify nothing broke
- Use `/commit` to commit the changes
```