pr-comments

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:

   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:

   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:

   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):

   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 numbernumber
   

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:

   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:

### #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:

### #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:

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:

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