Resolve PR Comments

Resolve PR Review Comments

Fetch unresolved review comments from a GitHub PR (inline threads, review-body observations, and issue-comment observations from the PR conversation), evaluate each one, fix or skip based on confidence, answer reviewer questions using the recalled rationale behind the change, and reply. Inline threads are answered with thread replies; issue-comment findings are answered with new PR conversation comments. Review-body findings flow through the same evaluate-and-fix pipeline; their outcomes land in the summary because a review body has no destination to post to.

Task Tracking

At the start, use TaskCreate to create a task for each step:

1. Fetch comments
2. Triage already-addressed feedback
3. Run /interpret-feedback skill
4. Split questions and change requests
5. Run /evaluate-findings skill
6. Resolve ambiguities
7. Run /resolve-findings skill
8. Verify fixes
9. Answer reviewer questions
10. Run /reply-to-pr-threads skill
11. Run /reply-to-pr-conversation skill
12. Summary

Step 1: Fetch Comments

Auto-detect owner, repo, and PR number from current branch if not provided. Then run scripts/fetch-pr-data.sh, which handles full pagination (reviews, review threads, inner comment pages for long threads, issue comments, commits) and emits a single merged JSON document:

bash <skill-dir>/scripts/fetch-pr-data.sh <owner> <repo> <pr_number>

Output shape:

{
  "meta":          { "title", "url", "headRefName", "baseRefName", "body" },
  "reviewThreads": [ { "id", "isResolved", "isOutdated", "comments": { "nodes": [ { "author", "body", "path", "line", "originalLine", "diffHunk" } ] } } ],
  "reviews":       [ { "author", "body", "state", "submittedAt" } ],
  "issueComments": [ { "author", "body", "createdAt", "url" } ],
  "commits":       [ { "commit": { "oid", "abbreviatedOid", "message", "committedDate" } } ]
}

Filter review threads to unresolved only. Filter reviews to those with a non-empty body, excluding PENDING state (unsubmitted drafts). Filter issue comments to those with a non-empty body.

Step 2: Triage Already-Addressed Feedback

Review bodies and PR conversation comments (issue comments) often pack multiple distinct concerns into one comment. Split each non-empty, non-PENDING review body and each non-empty issue comment into atomic observations, one per paragraph or bullet, so each can be evaluated on its own merits.

For every observation, check whether a subsequent commit already addresses it. Compare the source timestamp (submittedAt for review bodies, createdAt for issue comments) against each commit's committedDate; only commits after the source was posted can address it. Start with commit messages; read git show <oid> only when the message is ambiguous. A commit addresses an observation when its changes clearly resolve that specific concern. Touching the same area is not enough for an observation.

When an observation asserts a requirement or an intended behavior, compare that assertion against meta.body. The PR description is the author's own current statement of intent, so a description stating the opposite leaves a premise for Step 5 to settle. Record the contradiction against the observation and carry it forward, so Step 5 settles that premise once instead of re-deriving it for every finding the premise produced.

Classify each observation:

• Addressed: A subsequent commit resolves it. Record the commit SHA for the Step 12 summary.
• Unaddressed: No subsequent commit resolves it. Carry into Step 3, tagged with its source (review-body or issue-comment), the author, the observation text, any recorded contradiction with the PR description, and (for review bodies) the review state.

Review-body and issue-comment findings have no diffHunk, file path, or line reference. The downstream pipeline handles findings without a code location.

Triage inline threads on their replies. Look for a later reply that claims the concern is fixed and names the commit that fixed it. Verify two things about that commit. First, it is on the branch: it appears in commits, or git branch --contains <sha> reports the head branch. Second, it changed or deleted the thread's path. When both hold, classify the thread Addressed with that SHA and skip Steps 3 through 8 for it. Classify the rest Unaddressed and carry them into Step 3.

Step 3: Run /interpret-feedback Skill

Run the /interpret-feedback skill on the union of:

• Unaddressed inline threads from Step 2
• Unaddressed review-body findings from Step 2
• Unaddressed issue-comment findings from Step 2

Skip AI-reviewer accounts — match by known login (e.g., coderabbitai, copilot-pull-request-reviewer[bot]), not the [bot] suffix alone. Their structured feedback routes directly to /evaluate-findings.

If that leaves no items to interpret, skip the skill invocation.

For inline threads, include the diffHunk so the interpreters can see the code the reviewer was looking at. For outdated comments where line is null, use originalLine. For review-body and issue-comment findings, provide the observation text and the PR's changed-file list as context.

Tag each item with its source (inline-thread, review-body, or issue-comment) so later steps can route replies correctly.

Step 4: Split Questions and Change Requests

Classify each interpreted item as either a question or a change request based on the reconciled intent from Step 3.

• Question — the reviewer is asking for an explanation or wondering whether something is intentional. No code change requested. Examples: "Why this approach?", "Is this intentional?", "What is the benefit here?".
• Change request — the reviewer suggests a code change, flags a bug, or proposes an alternative. This includes soft-phrased suggestions ("could we ...", "consider ...") and rhetorical questions that imply a change ("Shouldn't this ...?", "Is there a reason this isn't ...?").

When in doubt, treat the item as a change request. The verdict from /evaluate-findings in Step 5 will catch genuine non-issues.

Produce two lists. Each entry retains the source tag, identifier (thread id for inline threads; a generated id for review-body and issue-comment findings), file path and line (use originalLine when line is null; omit for review-body and issue-comment findings), the reviewer's original text, any recorded contradiction with the PR description, and the reconciled intent from Step 3. Questions skip Step 5 and feed Step 9. Change requests feed Step 5.

Step 5: Run /evaluate-findings Skill

If Step 4 produced no change requests and Step 3 routed no AI-reviewer items here, skip the skill invocation.

Run the /evaluate-findings skill on the change requests from Step 4 and the AI-reviewer items Step 3 routed here, to triage each one. Questions are not evaluated here.

Review-body and issue-comment findings have no file or line reference. Scope their assessment to the PR's changed files as a whole, and do not treat the absent code location as a "code has diverged" early exit.

Step 6: Resolve Ambiguities

Collect items assigned an Escalate verdict by /evaluate-findings. If there are none, skip to Step 7.

Output all escalated items as a numbered list. For each item, show:

• The reviewer's original comment
• The competing interpretations or the reason for escalation
• The file and line reference, when available

Then use AskUserQuestion to ask how to handle them. State each question as the decision the user owns: what the code should do. Leave the reviewer's wording and code location to the numbered list above. Per item, the options are:

• Direct answer: "Do X" — assign an Accept verdict with the user's clarified intent. Step 7 picks it up as an accepted finding.
• Ask the reviewer: "Ask them Y" — queue a clarification question to be drafted in Step 10 (inline threads) or Step 11 (issue comments)
• Skip: Remove from processing

Whenever the item is costly to reverse (its resolution establishes a pattern others will follow, defines an interface, commits to a data shape, or imports a pattern the codebase has not used), and whenever you cannot recommend one of the three with conviction, add a fourth Get a second opinion option. It runs the /consult-codex skill for the soundest resolution on technical merit alone, independent of the changeset's original scope, naming any scope cost with the answer. On an item that turns on product intent, run it for what each resolution commits to, what reversing it costs, and what the prevailing convention is. Then resolve the item with that answer in hand, re-asking when the choice stays the user's.