Resolve Fixed PR Comments

Resolve Fixed PR Review Comments

Load ONLY open/UNRESOLVED PR review threads, verify each one against the CURRENT state of the codebase (the fix may be committed/pushed OR exist only as uncommitted local changes — both count), and resolve ONLY the threads that are genuinely fixed or no longer relevant. The single permitted write action is resolving a thread. Nothing else is touched.

Critical Guidelines

Violating the letter of these rules means failing the task. If you fail the task, you will be killed!

• When unsure, LEAVE THE THREAD UNRESOLVED. Better to leave a fixed comment unresolved than to wrongly resolve an unfixed one.
• You MUST load ONLY threads where isResolved/is_resolved is false. Skip resolved threads.
• You MUST observe only the CURRENT state of the codebase. Read the file as it exists NOW. Do NOT reason about how the code used to be, what a commit changed, or git history as evidence of a fix — only whether the requirement is satisfied in the current files counts.
• A fix is VALID whether it is already committed/pushed OR exists only as uncommitted local changes. Both are acceptable evidence. Inspect the working tree as-is.
• You MUST NOT modify code, create/edit/delete any file, or run tests, linters, formatters, or builds.
• You MUST NOT push, pull, commit, stash, checkout, switch, reset, revert, rebase, merge, cherry-pick, or perform ANY mutating git operation. ONLY read-only inspection (git status, git diff, git log, git branch) is allowed, and only to observe the current state.
• You MUST NOT add a comment to the PR, reply to a thread, submit a review, approve, or request changes. The ONLY write action permitted against GitHub is resolving a thread that is genuinely fixed.
• You MUST be critical and perfectionist. A comment is "fixed" ONLY when ALL of its requirements are FULLY satisfied in the current codebase. Partially-addressed comments, unaddressed nitpicks, and "close enough" changes stay UNRESOLVED.
• You MUST NOT resolve a thread you did not verify against an actual file. No verification → no resolve.

Red Flags - STOP and Leave Unresolved

If any of these describe your reasoning, do NOT resolve the thread:

• "The fix is probably there, I'll resolve it." → No. Verify against the current file or leave it.
• "The commit message says it was fixed." → Commit messages and history are NOT evidence. Read the current file.
• "Most of the comment is addressed." → Partial ≠ fixed. Leave unresolved.
• "It's just a nitpick, resolving it cleans up the PR." → Unaddressed nitpicks stay unresolved.
• "It's no longer relevant because the code moved." → Only resolve if the requirement is genuinely satisfied or genuinely obsolete in the CURRENT code — not because it's inconvenient to verify.
• "I'll quickly fix it myself, then resolve." → FORBIDDEN. No code edits. If it isn't already fixed, leave it unresolved.
• "I'll reply explaining why I resolved it." → FORBIDDEN. No replies, no comments. Resolve silently or leave it.
• "I'll resolve all of them since the branch looks done." → Resolve per-thread, each on its own verified evidence.

Rationalization Table

How to Use

Work one thread at a time: (1) load unresolved threads with their GraphQL node id, (2) for each, read the current file(s) referenced and check every requirement against the present content, (3) resolve ONLY if fully satisfied/obsolete, otherwise skip. Report what was resolved and what was left and why.

Step 0: Verify what tools are available

1. Check if GitHub CLI is installed and authenticated:

   gh auth status

2. Check if the GitHub MCP server is available:

   mcp__MCP_DOCKER__pull_request_read

   or simular command without MCP_DOCKER prefix, if installed directly.

• if both are available, use any that have enough accesses to the repository.
• if github mcp server avaiable but have different structure, adjust in order to fit the expected structure.
• if none is available, try to load directly through curl in case if it is public repository. If it is private, ask user to install GitHub CLI or GitHub MCP server.
• if MCP server not installed, but github cli is installed, but not authenticated, ask user to run gh auth login to authenticate.

Step 1: Resolve the Target PR

• An explicit PR argument ALWAYS takes precedence over current-branch resolution. If a PR number or URL was passed, use it (a URL like https://github.com/{owner}/{repo}/pull/{n} → number {n}) and do NOT consult the current branch.
• Otherwise default to the PR of the CURRENT branch:

gh pr view --json number,url,headRefName   # current branch's PR

• Resolve repo owner/name: gh repo view --json owner,name.
• If no PR exists for the branch, gh pr view errors with "no pull requests found" — STOP and report that no PR is associated with the branch (ask for a PR number/URL).

Step 2: Retrieve UNRESOLVED Comments

Resolved/unresolved is a GraphQL reviewThreads { isResolved } concept — the REST /pulls/{n}/comments endpoint does NOT expose it. Use one of the two approaches below; if the primary is unavailable, fall back to the other.

Primary: gh CLI (GraphQL)

Filter isResolved == false directly in the jq:

gh api graphql -f query='
query($owner:String!,$repo:String!,$pr:Int!){
  repository(owner:$owner,name:$repo){
    pullRequest(number:$pr){
      reviewThreads(first:100){
        nodes {
          id
          isResolved
          isOutdated
          path
          line
          startLine
          originalLine
          comments(first:50){
            nodes { author{login} body diffHunk url }
          }
        }
      }
    }
  }
}' -F owner=OWNER -F repo=REPO -F pr=PR_NUMBER \
  --jq '[.data.repository.pullRequest.reviewThreads.nodes[]
         | select(.isResolved==false)
         | {id, path, isOutdated,
            line: (.line // .startLine // .originalLine),
            comments: [.comments.nodes[]
             | {author: .author.login, url, body, diffHunk}]}]'

This returns each unresolved thread with its GraphQL node id (needed to resolve it in Step 4), its file path, an isOutdated flag, a usable line, and ordered comments (author, body, permalink url, diffHunk).

IMPORTANT: For OUTDATED threads line is null (the diff moved). The jq above already falls back line // startLine // originalLine, so line is never null when any anchor exists. When ALL three are null, omit the :<line> segment entirely in the template — never render path:null.

Fallback: GitHub MCP

If the GitHub MCP server (MCP_DOCKER) is available, use the mcp__MCP_DOCKER__pull_request_read tool with method: "get_review_comments":

mcp__MCP_DOCKER__pull_request_read
  method: "get_review_comments"
  owner: "OWNER"
  repo: "REPO"
  pullNumber: PR_NUMBER
  perPage: 100

It returns review_threads[], each with is_resolved, is_outdated, is_collapsed (all snake_case — verified against this tool's response) and comments[] (body, path, author, html_url). Keep only threads where is_resolved is false. Note the MCP comment objects expose path but NOT a line number, so use the html_url as the location anchor. Paginate with after: <endCursor> while pageInfo.hasNextPage is true.

The MCP review-thread object also carries the thread node id (the PRRT_... node ID). Capture it per thread — mcp__MCP_DOCKER__pull_request_review_write with method: "resolve_thread" needs it in Step 4.

Step 3: Verify Each Thread Against the CURRENT Codebase

For EACH unresolved thread, gather the concrete requirement(s) and verify them against the present file content. Apply the Critical Guidelines strictly.

1. Identify what the comment actually requires. If a HUMAN reviewer left feedback, the requirement is THAT feedback. If only a bot/AI suggestion exists (Claude, CodeRabbit, Copilot, etc.), the requirement is that suggested fix. A thread may contain multiple requirements — ALL must be satisfied to count as fixed.
2. Open the referenced file(s) at path and read the CURRENT content (use the Read tool / git show :<path> is NOT needed — just read the working-tree file). Optionally run git diff -- <path> or git status ONLY to observe current uncommitted changes; never to reason about history as proof.
3. Decide the disposition:

Do NOT edit code to make a thread pass. Do NOT run tests/builds/linters to "check". Verification is reading the current source and judging whether the requirement is met.