Resolve GitHub Review Comments
When to use
Use this skill when a pull request has unresolved inline review comments and you need a repeatable, auditable closure workflow.
Typical triggers (skill should activate on all of these):
URL patterns — activate immediately:
https://github.com///pull/#pullrequestreview-
https://github.com///pull/
(when context implies review work)
Explicit user requests:
"Fix the review comments"
"Address the review feedback on this PR"
"There are unresolved review comments — fix them"
"Resolve the conversations on this PR"
"Handle all unresolved comments on this PR"
"For each review comment: fix, test, commit, reply, resolve"
"Close the open review threads"
"Check this review and resolve the conversation when fixed"
"Resolve outstanding review feedback"
"The PR has changes requested — fix it"
Implicit / agent-detected:
A PR is in "changes requested" state and the agent is asked to work on it
A PR has unresolved review threads and the user asks to improve or merge the PR
An agent working on a PR detects open review conversations
When not to use
Do not use this skill when:
no unresolved review comments exist,
the request is only to summarize or describe feedback without making code changes,
all targeted threads are already resolved or outdated and acknowledged,
the branch/worktree is intentionally read-only.
Required inputs
Collect before execution:
repository owner/name,
pull request number or URL,
optional review id to scope comments (for example
pullrequestreview-
),
branch/worktree decision,
required validation commands for the repository.
When a review URL is provided
(
github.com///pull/#pullrequestreview-
),
auto-extract owner, repo, PR number, and review id from it.
Only branch/worktree choice and validation commands still need confirming.
Optional context:
linked issue reference (for example
equinor/fusion-core-tasks#432
),
commit granularity preference when comments overlap the same file.
Instructions
Follow this phase order unless the user explicitly asks for a different sequence: fetch → analyze → fix → validate → push → reply → resolve → verify. Do not interleave GitHub thread mutations with code-editing retries.
Ask whether to use a dedicated git worktree
Ask this before any other workflow questions.
If yes, use/create the worktree and continue there.
Gather unresolved comments and create working tracker
If a review URL with
pullrequestreview-
was provided, parse owner, repo, PR number, and review id from it before fetching.
Copy or open
assets/review-resolution-checklist.md
—this becomes your working document.
Fill in the context section and update the comment tracking table as you work through each thread.
Fetch review threads for the PR and filter unresolved threads.
If a specific review id or review URL is provided, limit to comments from that review.
Within the targeted review, collect all comments associated with that review id (do not include replies from other reviews unless explicitly requested).
Build a working list with: thread id, comment id, parent review id, file path, original comment body, and all subsequent replies in that thread (including contributor replies).
Read the full reply chain for each thread — contributors may have added clarifications, constraints, or additional context that must be taken into account when deciding how to resolve the comment.
Capture a baseline list of targeted thread ids and unresolved-thread count before any GitHub mutation.
Understand, research, and judge each comment
Read the referenced file(s) and nearby logic.
Decide whether the feedback is correct, partially correct, outdated, or incorrect against the current code, requirements, and surrounding context.
Reviewers are not automatically correct; do not make code churn just to satisfy a comment that is stale or wrong.
If the feedback is correct, verify root cause and identify the smallest safe fix.
If the feedback is clearly incorrect or outdated, prepare a concise evidence-based reply instead of changing code unnecessarily.
If uncertain, inspect adjacent tests/usages before editing.
If doubt remains after local research, ask the user before making code changes or mutating that review thread.
Fix, check, commit (per comment)
Apply focused code/doc changes only for comments you judged valid or partially valid.
Run targeted checks first, then required repo checks.
Create one commit per comment when practical.
If two comments require one inseparable change, use one commit and map both comments to that commit in replies.
For comments you decline, record the reasoning in the tracker so the eventual reply is explicit and auditable.
Push once after all fixes
After all comment-related commits are created, push branch updates once.
Reply and resolve each review comment
Before any thread mutation, prefer structured tooling in this order:
dedicated GitHub MCP review-thread reply/resolve tools exposed in the current client session,
the bundled GraphQL assets or bundled
scripts/resolve-review-comments.sh
,
never ad hoc temporary Python scripts, one-off batch helpers, or blind
gh api
retry loops.
Prepare exactly one planned reply per targeted thread from the checklist/tracker before posting anything.
Re-fetch the current thread state before retrying if a reply/resolve attempt errors, times out, or returns an uncertain result.
For each thread, these two steps are mandatory and must happen together in order unless the thread is still uncertain and waiting for user input:
Post a reply
on the thread: either describe what changed and include the commit hash(es), or explain why no code change was made because the comment is incorrect/outdated.
Resolve the thread
immediately after the reply is posted — never before.
Post at most one reply attempt per thread per run.
If an equivalent agent-authored reply already exists, do not post another reply; reuse it and only resolve if the thread is still unresolved.
If a different agent-authored reply already exists, stop and inspect manually rather than stacking another comment.
Do not resolve a thread that is still uncertain; escalate it to the user first.
Never resolve a thread without a reply. Never post a reply without then resolving the thread.
Keep replies specific: name the file/line changed and the commit, not just "fixed".
Verify closure state
Re-check review threads and confirm no targeted unresolved threads remain.
Confirm the targeted unresolved-thread count dropped to zero and no duplicate agent replies were created during this run.
Re-check latest CI status if the workflow expects green checks.
Ask whether to request a new review from the original review author
After fixes are pushed and threads are resolved, ask if the user wants to request a new review from the author of the review comments.
If yes, request review from that reviewer username and report that the request was sent.
Optional scripted execution
Use
scripts/get-review-comments.sh
to fetch matching review comments (including sub-comments associated with the review id).
Results are limited to the first 100 review threads and first 100 comments per thread.
Example test:
skills/.experimental/fusion-github-review-resolution/scripts/get-review-comments.sh --owner equinor --repo fusion-skills --pr 27 --review-id 3837647674
Use
--include-outdated
when you need comments from outdated matching threads.
Use
scripts/resolve-review-comments.sh
to reply+resolve matching threads with a dry-run-first duplicate-reply guard.
Keep default dry-run behavior; use
--apply
only after fixes are committed and pushed.
By default the script refuses to add another authenticated-user reply to a thread that already contains one; use
--allow-additional-reply
only after manual inspection.
Example dry-run:
skills/.experimental/fusion-github-review-resolution/scripts/resolve-review-comments.sh --owner equinor --repo fusion-skills --pr 27 --review-id 3837647674 --include-resolved
Example apply:
skills/.experimental/fusion-github-review-resolution/scripts/resolve-review-comments.sh --owner equinor --repo fusion-skills --pr 27 --review-id 3837647674 --apply --message "Addressed in : ."
Tooling map (MCP vs GraphQL)
Use GitHub MCP tools for high-level PR operations and any dedicated review-thread mutations the current client exposes. Use GraphQL for thread-level review operations when MCP coverage is missing.
Workflow action
Preferred tool
Notes
Request reviewer / update PR metadata
mcp_github_update_pull_request
Works for collaborator reviewers and standard PR updates.
Create or submit PR review
mcp_github_pull_request_review_write
Handles pending review lifecycle actions.
Add general PR comment
mcp_github_add_issue_comment
Adds issue-style comment to PR conversation, not inline thread reply.
List review threads and comments
assets/pull-request-review-threads.graphql
Use with
gh api graphql -f query=@assets/pull-request-review-threads.graphql
for thread-level context.
Count unresolved threads for specific review id
assets/unresolved-thread-count-for-review.graphql
Post-process response (for example with
jq
) to filter by review id and unresolved state.
Reply to a review thread
Dedicated MCP review-thread reply tool
, otherwise
assets/add-pull-request-review-thread-reply.graphql
Prefer the MCP tool when available; otherwise use the bundled thread-scoped mutation instead of ad hoc scripts.
Resolve a review thread
Dedicated MCP review-thread resolve tool
, otherwise
assets/resolve-review-thread.graphql
Use the matching structured tool for the current client/session. ⚠️ GraphQL note:
resolveReviewThread
uses
threadId
, not
pullRequestReviewThreadId
.
List PR reviews (review URL/id lookup support)
assets/pull-request-reviews.graphql
Useful when starting from review URL context.
Pro tip:
See each
.graphql
file in assets for complete mutation/query syntax and parameter names.
GraphQL cost awareness
Review-resolution workflows make multiple GraphQL mutation calls (reply + resolve per thread). Be conservative:
Mutations cost 5 secondary-limit points each (vs 1 for read queries). Budget accordingly when processing many threads.
Pause at least 1 second between consecutive mutation calls to avoid secondary rate limits.
Keep
first
/
last
connection arguments small (prefer
first: 100
only when you need all threads in a single page).
If a secondary rate-limit error or
retry-after
header is returned, stop processing and respect the indicated wait before retrying.
Always prefer a dedicated MCP review-thread tool over raw GraphQL when the client exposes one.
Token budget guidance
Fetch the full thread list once and reuse it for all per-thread work; do not re-fetch threads between reply and resolve.
Budget estimate: for N unresolved threads expect ~1 list call + N reply mutations + N resolve mutations = 1 + 2N calls. A 10-thread review costs ~21 calls.
If the thread count exceeds 15, warn the user about rate-limit risk before starting mutations and offer to batch in smaller groups.
Cache PR metadata (title, branch, CI status, changed files) from the first fetch and reuse it for commit messages and replies.
Avoid redundant PR-level reads between steps; the data does not change within a single resolution run.
Expected output
Return a concise report containing:
comments processed count,
disposition summary (fixed, declined with rationale, escalated to user),
files changed,
commit list (hash + message),
validation commands run and outcomes,
confirmation of push,
reply/resolve confirmation per thread,
completed checklist location,
any remaining unresolved threads or blockers.
Linked issue usage
When an issue is provided (for example
equinor/fusion-core-tasks#432
):
mention the issue in progress/final summaries,
keep implementation aligned with issue scope,
avoid expanding to unrelated PR automation.
Safety & constraints
This skill is mutation-capable. Repository-local workflow instructions take precedence over inline guidance when they conflict.
Never expose secrets or tokens in logs/replies.
Prefer argv-based process execution over shell-interpolated command strings.
Keep diffs minimal and scoped to review feedback.
Do not assume review feedback is correct; reason about it against the code and requirements first.
If a comment remains ambiguous after research, ask the user instead of guessing.
Do not resolve a thread without posting a concrete fix reply.
Do not claim checks passed unless commands were actually run.
Do not force-push; use regular commits and a single push after all fixes.
If a comment is outdated but still unresolved, either:
resolve with a clear explanation and commit reference, or
leave unresolved and report why.
In scripted mode, keep default dry-run behavior and require explicit
--apply
for mutations.