Handle Pr Review

Fetch PR review comments, triage them (fix, challenge, or skip), apply holistic fixes, resolve threads, and post a summary.

<!-- sync: canonical version. .cursor/skills/handle-pr-review/SKILL.md is a simplified subset — keep the summary comment step aligned. -->

## Parameters

- `pr` — PR number or URL (optional; auto-detected from current branch if omitted)
- `auto` — `true` or `false` (default `false`). When `true`, skip the operator confirmation gate (Step 3) and proceed directly to holistic analysis and fixes. Intended for build-loop autonomous invocation.

---

## 0. Prerequisites

Verify GitHub CLI authentication before any API calls:

```bash
gh auth status

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

1. Identify PR

Detect from context (branch, parameter, or URL). Prefer:

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

Fall back to gh api by head branch or listing PRs.

Check PR state before proceeding:

State	Action
Open	Proceed normally
Draft	Proceed, but note that the PR is still in draft — reviewer expectations may differ
Merged / Closed	Stop and inform user; no action to take

2. Fetch unresolved threads (GraphQL)

Use GraphQL to get review threads with thread and comment IDs (needed to resolve threads and post replies). REST does not expose isResolved or thread IDs.

gh api graphql -f query='
  query($owner:String!,$repo:String!,$pr:Int!) {
    repository(owner:$owner,name:$repo) {
      pullRequest(number:$pr) {
        reviewThreads(first:100) {
          pageInfo { hasNextPage endCursor }
          nodes {
            id
            isResolved
            isOutdated
            path
            line
            viewerCanResolve
            comments(first:30) {
              nodes {
                id
                databaseId
                body
                author { login }
                path
                line
                originalLine
                createdAt
              }
            }
          }
        }
      }
    }
  }' -f owner=OWNER -f repo=REPO -F pr=NUMBER

Post-fetch processing:

• Filter to isResolved === false. Collect every comment per thread together — thread context matters.
• Outdated threads (isOutdated === true): the referenced code has changed since the comment was posted. Read the current code — the concern may already be addressed. If so, resolve the thread without a code change and note it in the summary.
• Pagination: If pageInfo.hasNextPage is true, re-query with reviewThreads(first:100, after:"ENDCURSOR") using the endCursor value. Repeat until all pages are collected.

Note on IDs: The databaseId on each comment is the numeric REST ID needed for the reply endpoint in step 9. The id field is the GraphQL node ID needed for resolving threads in step 8. Keep both.

3. Triage — classify each thread

Before writing any code, read all unresolved threads and the surrounding source code, then classify each:

Category	When	Action
Fix	Feedback is correct: real bug, valid improvement, catches something missed, or aligns with project conventions	Plan the code change
Fix (adjusted)	Core concern is valid but the suggested approach isn't ideal — you'll address the underlying issue your own way	Plan your solution; note the deviation
Challenge	Feedback is incorrect, conflicts with project conventions, misunderstands context, would degrade the code, or is overly pedantic on a subjective point	Draft a respectful reply with evidence
Skip	Marked "nit" / "optional" / "take it or leave it", already resolved by another fix, or outdated thread whose concern was addressed by subsequent commits	Note it; no action unless user asks

Ground rules:

• Every comment deserves critical evaluation. Reviewers can be wrong; the goal is the best code, not maximum compliance.
• If a thread has multiple back-and-forth replies, read the entire conversation. Earlier messages may contain agreements, context, or clarifications that change the conclusion.
• Group related threads. If 3 threads raise the same concern in different files, plan one cohesive fix, not 3 isolated patches.
• Automated comments (CodeRabbit, CodeQL, Copilot, SonarCloud, etc.): triage the same way. Bots produce false positives and suggestions that conflict with project style. Do not auto-accept.

How to challenge well:

Be respectful but direct. Cite project conventions, existing patterns, or technical reasoning.

Scenario	Example reply
Architecture disagreement	_"We co
```