Verify what PR review comments have been addressed (committed/pushed OR uncommitted local changes) and resolve the threads that are genuinely fixed or no longer relevant.

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 Excuse Reality "The fix was committed, so it's done." Read the CURRENT file and confirm the requirement is satisfied. Committed ≠ verified. "Git diff shows the change." A diff is historical reasoning. Confirm the requirement holds in the current file content, not that something changed. "It's uncommitted, so it doesn't count yet." Uncommitted local changes ARE valid evidence. Inspect the working tree as is. "I'll just make the small fix and resolve." Editing code is strictly forbidden. Unfixed → unresolved. "A reply would be polite." No replies/comments. The only write action is resolving. "Nitpick is trivial, resolve to tidy up." Unaddressed = unresolved, regardless of triviality. "Reviewer would obviously accept this." You are not the reviewer. Resolve only on satisfied requirements, not on predicted approval. "Not 100% sure, but likely fixed." Unsure = leave unresolved. 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: 2. Check if the GitHub MCP server is available: 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: 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: 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" : 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: Disposition Condition Action FIXED Every requirement in the thread is fully satisfied in the current file content (committed OR uncommitted). Mark to resolve in Step 4. OBSOLETE The code the comment referred to genuinely no longer exists / the concern is genuinely moot in the current code. Mark to resolve in Step 4. NOT FIXED Any requirement is unmet, partially met, or you cannot confirm it from the current files. LEAVE UNRESOLVED. Do nothing. UNSURE You cannot confidently verify satisfaction. LEAVE UNRESOLVED. Do nothing. 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. Step 4: Resolve the Genuinely Fixed Threads For each thread marked FIXED or OBSOLETE, resolve it using the thread's node id captured in Step 2. Use whichever path is available (prefer the one you used to load comments). Resolving an already resolved thread is a harmless no op. Primary: gh CLI (GraphQL resolveReviewThread mutation) The resolveReviewThread mutation takes a ResolveReviewThreadInput whose required field is threadId (the GraphQL node id from Step 2's reviewThreads.nodes[].id ). Verified against GitHub's GraphQL schema via introspection ( ResolveReviewThreadInput.threadId: ID! ). On success the response is {"data":{"resolveReviewThread":{"thread":{"id":"PRRT ...","isResolved":true}}}} . Confirm isResolved is true . Fallback: GitHub MCP ( pull request review write → resolve thread ) The GitHub MCP server CAN resolve threads via mcp MCP DOCKER pull request review write with method: "resolve thread" . It requires only threadId (the thread node ID, e.g. PRRT kwDOxxx ). Per the tool's own documentation, owner / repo / pullNumber are NOT used by this method, but the tool schema marks them required — pass the PR's owner/repo/pullNumber to satisfy validation; they are ignored for the resolve operation. If the MCP server is NOT available or its pull request review write lacks resolve thread , fall back to the gh CLI GraphQL mutation above. ONLY resolve thread is permitted. Do NOT use unresolve thread , create , submit pending , delete pending , or any event (APPROVE/REQUEST CHANGES/COMMENT) — those are write actions this skill forbids. Parameters Explained Parameter Path Type Required Description threadId gh CLI & MCP string ( ID! ) Yes The review thread's GraphQL node id ( reviewThreads.nodes[].id , e.g. PRRT kwDO... ). This is the thread id, NOT a comment id and NOT a numeric REST id. method MCP string Yes (MCP) Must be "resolve thread" . owner MCP string Yes (MCP schema) Repo owner. Ignored by resolve thread but required by the tool schema. repo MCP string Yes (MCP schema) Repo name. Ignored by resolve thread but required by the tool schema. pullNumber MCP number Yes (MCP schema) PR number. Ignored by resolve thread but required by the tool schema. clientMutationId gh CLI string No Optional dedupe token on the GraphQL input. Omit normally. Step 5: Report Summarize without taking any further action: Target PR (number + url). Count of unresolved threads loaded. Threads RESOLVED, each with its path:line (or path if outdated) and a one line reason (FIXED / OBSOLETE) plus the evidence in the current code. Threads LEFT UNRESOLVED, each with a one line reason (NOT FIXED / partial / UNSURE). Any limitation hit (e.g. MCP unavailable, all threads already resolved). Examples Input: resolve fixed pr comments (no argument, current branch has PR 42) Process: Load PR 42's unresolved threads (Step 2).

resolve-fixed-pr-comments