---

name: review-pr-comments description: > Check a PR for unresolved review comments, assess each one, apply fixes where needed, and resolve addressed threads via the GitHub API. Use this skill whenever the user mentions PR comments, review threads, unresolved feedback, or addressing reviewer suggestions — even if they just say "fix the comments", "close out the review threads", or "address the feedback".

Review & Resolve PR Comments

Fetch every unresolved review thread on a PR, decide for each whether a code fix is needed, apply the fix (or confirm it's already done), then resolve the thread via gh GraphQL. Ask the user whenever a decision is genuinely ambiguous.

When to Use This Skill

• User says "address the PR comments" or "fix the review comments"
• User says "resolve comments on PR #N" or pastes a PR URL
• User says "check the open comments on my PR"

---

Steps

Execute in order. Stop and report if any step fails.

Step 1: Identify the PR

If the user provided a PR number or URL, extract the number.

Otherwise, try to detect the PR automatically from the current branch/worktree:

gh pr view --json number,url,headRefName 2>/dev/null

If that returns a PR, use it and inform the user which PR was detected (number

• title) before continuing.

If no PR is found automatically, ask:

Which PR number (or URL) should I review?

Derive OWNER, REPO, PR_NUMBER from the URL or from the current repo's git remote get-url origin. Handle both HTTPS (https://github.com/OWNER/REPO.git) and SSH (git@github.com:OWNER/REPO.git) remote formats.

Step 2: Switch gh to the repo owner account (if needed)

Extract the currently active GitHub username:

gh api user --jq '.login'

If that username does not match OWNER (derived in Step 1), switch:

gh auth switch --user <OWNER>

Note the original username so you can restore it at the end. Do NOT rely on gh auth status to determine the active user — its output format is harder to parse reliably. Use gh api user --jq '.login' instead.

Step 3: Fetch ALL unresolved review threads

Use the GitHub GraphQL API to get every thread — paginate if needed. The REST endpoint can truncate output; always use GraphQL:

gh api graphql -f query='
{
  repository(owner:"OWNER", name:"REPO") {
    pullRequest(number:PR_NUMBER) {
      reviewThreads(first:100) {
        nodes {
          id
          isResolved
          isOutdated
          comments(first:20) {
            nodes {
              databaseId
              path
              line
              body
            }
          }
        }
      }
    }
  }
}' --jq '.data.repository.pullRequest.reviewThreads.nodes[]
         | select(.isResolved == false)
         | {
             threadId: .id,
             outdated: .isOutdated,
             commentId: .comments.nodes[0].databaseId,
             path: .comments.nodes[0].path,
             line: .comments.nodes[0].line,
             body: .comments.nodes[0].body
           }'

Record the full list. If there are zero unresolved threads, report that and stop.

Step 4: Read the current file for each thread

For every unresolved thread, read the relevant file at the commented line to understand the current state of the code:

• If the thread is outdated (isOutdated: true), the code has already changed. Read the file to confirm the concern is addressed.
• If the thread is not outdated (isOutdated: false), the commented line still exists. Read it and decide:
  • Is the issue already fixed (e.g. a test was added in a new file, or the change was applied elsewhere)?
  • Does it still need a fix?
  • Is the suggestion wrong / inapplicable (stale logic, wrong assumption)?

Step 5: Triage each thread

Categorise every thread into one of three buckets:

| Bucket | Meaning | Action | | ------------------ | ------------------------------------------------------------- | --------------------------------------- | | already-fixed | The code concern is addressed; comment is just not resolved | Resolve the thread, no code change | | needs-fix | The issue is real and present in the current code | Apply the fix, then resolve | | not-applicable | The suggestion is wrong, stale, or intentionally not followed | Post a reply explaining why, then resolve |

When in doubt, pause and ask the user before placing a thread in any bucket. Never silently skip a thread.

Step 6: Apply fixes

For threads in the needs-fix bucket:

1. Make the minimal correct change to the file.
2. Build and run tests using the project's standard commands (e.g. pnpm build and pnpm vitest run for pnpm projects; npm test or yarn test for others — check package.json scripts if unsure) to confirm nothing breaks.
3. If tests fail, fix them or pause and ask the user.
4. Commit the fix:

git add <files>
git commit -m "fix: <short description of what was fixed>

Addresses PR review comment: <comment body summary>"
git push

Collect the thread IDs of all fixed threads.

Step 7: Resolve threads

For threads in not-applicable, first post a reply comment explaining why the suggestion wasn't followed, so the reviewer isn't left wondering:

gh api repos/OWNER/REPO/pulls/PR_NUMBER/comments \
  --method POST \
  -f in_reply_to=COMMENT_DATABASE_ID \
  -f body="<brief explanation: e.g. 'This is intentional — X because Y'>"

Then, for every thread in already-fixed, needs-fix (now fixed), and not-applicable, resolve via GraphQL:

gh api graphql -f query="
  mutation {
    resolveReviewThread(input: {threadId: \"THREAD_ID\"}) {
      thread { isResolved }
    }
  }
" --jq '.data.resolveReviewThread.thread.isResolved'

Verify the result is true before moving to the next thread.

Step 8: Restore original gh account

If the active account was switched in Step 2, restore it:

gh auth switch --user <ORIGINAL_ACCOUNT>

Step 9: Report

Summarise what was done:

• How many threads were found
• How many were already-fixed (just resolved)
• How many needed and received a fix
• How many were not-applicable (resolved with explanation)
• Any that were skipped pending user input (list them explicitly)

---

Important Notes

• Never resolve a thread without first confirming the underlying concern is addressed — either in the current code or with a new commit.
• Outdated ≠ resolved. An outdated thread may still represent a real issue in refactored code.
• Ask the user for anything that involves a design choice, trade-off, or intentional deviation from the reviewer's suggestion.
• This skill resolves threads under the repo owner's account. Always restore the original gh account at the end.