▸ Agent Skills
4 min read

Triage and resolve GitHub PR review comments with categorized action plans and approval-gated execution


Tend to GitHub PR Comments

Consult the gh pr manual for more details.

Pull all review comments from the current branch’s PR, build a plan to address each one, align with the developer, then execute.

1. Prerequisites

Verify the environment is ready.

Check authentication:

gh auth status

If not authenticated, stop and tell the user to run gh auth login.

Check current branch:

git branch --show-current

Confirm you are not on the default branch. If you are, stop and ask the user to check out their feature branch.

2. Identify the PR

Get PR details:

gh pr view --json number,url,headRefName,baseRefName

If no PR exists for the current branch, stop and tell the user.

Get repo owner/name:

gh repo view --json nameWithOwner -q '.nameWithOwner'

Parse this into {owner} and {repo} for API calls below.

3. Pull All Comments

Fetch three types of comments and combine them.

Inline review comments:

gh api repos/{owner}/{repo}/pulls/{pr_number}/comments --paginate

Review-level comments:

gh api repos/{owner}/{repo}/pulls/{pr_number}/reviews --paginate

General PR conversation comments:

gh api repos/{owner}/{repo}/issues/{pr_number}/comments --paginate

Get current user for filtering:

gh api user -q '.login'

For each comment, extract: id, node_id, user.login, body, path, line/original_line, diff_hunk, in_reply_to_id, created_at.

Filter out:

  • Bot comments (user.type == "Bot")
  • Already-resolved threads

Note: Do NOT filter out comments authored by the current user. Users often leave self-review comments on their own PRs as reminders or action items to address.

Group inline review comments into threads by in_reply_to_id. The latest comment in a thread determines the thread’s status.

If zero comments remain after filtering, report “No open PR comments to address” and stop.

4. Assess and Categorize

For each comment or thread, read the comment body, the referenced file at the indicated line, and the diff hunk. Classify into one of these categories:

CategoryDescriptionExample
FixClear, actionable code change requested“This should use === not ==”
InvestigateNeeds codebase exploration before deciding“Is this duplicated anywhere else?”
DiscussDesign question, trade-off, or needs clarification“Should we use strategy A or B here?”
AcknowledgeFYI or praise, no action needed“Nice refactor”
OutdatedComment on code that has already changedDiff hunk no longer matches file

Rules:

  • For Fix items: read the actual file before proposing a change. Do not guess.
  • For Investigate items: note what to explore but do not explore yet.
  • For Discuss items: summarize the question and prepare to surface it.
  • For Outdated detection: check if the diff_hunk still matches the current file content or if position is null.

5. Present the Plan

Stop here and present the plan to the user. Use this format:

## PR Comment Triage: {pr_url}

### Fix ({count})

- [ ] **{file}:{line}** - {summary of what to change}
  > {abbreviated reviewer comment}

### Investigate ({count})

- [ ] **{file}:{line}** - {what to explore and why}
  > {abbreviated reviewer comment}

### Discuss ({count})

- [ ] **{file}:{line}** - {question or design decision}
  > {abbreviated reviewer comment}

### Acknowledge ({count})

- {comment summary} - will resolve, no action needed

### Outdated ({count})

- {comment summary} - code has changed, will resolve

Ask the user:

Here is the plan for addressing the PR comments. Do you want to:

  1. Proceed as-is
  2. Reclassify any items (e.g., move a Fix to Discuss)
  3. Skip specific items

Let me know before I start making changes.

Do not proceed until the user confirms.

6. Execute the Plan

Work through the approved plan in this order:

  1. Fix items first - make code changes one at a time
  2. Investigate items - explore the codebase, then either fix or surface findings to the user
  3. Discuss items - present findings and context, ask the user for direction

If an Investigate or Discuss item becomes clear during execution, reclassify it to Fix and proceed.

After all items are addressed, show a summary:

## Changes Made

| File | Line | Category    | Action Taken              |
| ---- | ---- | ----------- | ------------------------- |
| …    | …    | Fix         | Changed X to Y            |
| …    | …    | Investigate | Found Z, no change needed |
| …    | …    | Discuss     | User decided to defer     |

7. Resolve Comment Threads

Immediately after execution completes, resolve all addressed comment threads on GitHub. Do NOT wait for user confirmation - this happens automatically for all Fix, Investigate (that were resolved), Acknowledge, and Outdated items.

Skip resolution only for Discuss items the user explicitly deferred.

A review comment has no field back to its parent thread, so you cannot go directly from node_id to a thread ID. Instead, list the PR’s review threads and match each thread to the comment you addressed by its databaseId (the REST id from step 3) or node id:

gh api graphql --paginate -f query='
query($owner: String!, $repo: String!, $pr: Int!, $endCursor: String) {
  repository(owner: $owner, name: $repo) {
    pullRequest(number: $pr) {
      reviewThreads(first: 100, after: $endCursor) {
        nodes {
          id
          isResolved
          comments(first: 100) {
            nodes {
              id
              databaseId
            }
          }
        }
        pageInfo {
          hasNextPage
          endCursor
        }
      }
    }
  }
}' -f owner="{owner}" -f repo="{repo}" -F pr={pr_number}

The thread whose comments contains your addressed comment (databaseId == the REST id, or id == the node_id) is the one to resolve; take its id.

Then resolve:

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

8. Wrap Up

Ask the user:

All comments have been addressed and {M} threads resolved on GitHub. Ready to:

  1. Commit with message “Address PR review comments” (edit to taste)
  2. Push to remote

Proceed? Or would you like to review the changes first?

Do not proceed until the user confirms.

Commit and push:

git add <specific changed files>
git commit -m "Address PR review comments"
git push

Report final status:

## Done

- {N} comments addressed
- {M} threads resolved on GitHub
- Commit: {short_sha}
- PR: {pr_url}

Last updated Oct 08, 2026