resolve-fixed-pr-comments

Files (1)

• SKILL.md

SKILL.md (first lines)

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

   ```bash
   gh auth status
   ```

2. Check if the GitHub MCP server is available:

   ```bash
   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:

```bash
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:

```bash
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`).

From NeoLabHQ/context-engineering-kit, GPL-3.0.

More from NeoLabHQ/context-engineering-kit