Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
equinor avatar

Fusion Github Review Resolution

  • 1.8k installs
  • 1 repo stars
  • Updated August 4, 2026
  • equinor/fusion-skills

Automated resolution of unresolved GitHub PR review threads by evaluating comment validity, applying code fixes, posting replies with rationale, and resolving threads.

About

This skill automates the closure of unresolved GitHub PR review comments through a structured workflow: fetch threads, evaluate correctness of each comment against current code, apply focused fixes for valid feedback, reply with rationale or commit hashes, push changes once, and resolve threads. Developers use it when PRs have review feedback to address, needing an auditable, repeatable process that distinguishes between correct, outdated, and incorrect comments. Key workflows include parsing PR/review URLs to extract context, building a working checklist to track decisions, running targeted validation before committing, and using GitHub MCP or GraphQL tools to post replies and resolve threads atomically.

  • Parses GitHub PR review URLs (#pullrequestreview-<id>) to auto-extract owner, repo, PR number, and review scope
  • Evaluates each review comment against current code and requirements; does not apply changes for stale or incorrect feedb
  • Creates one commit per validated comment and performs a single push after all fixes, reducing CI overhead
  • Posts concrete replies naming changed files and commit hashes before resolving threads; never resolves without a reply
  • Uses GitHub MCP tools or bundled GraphQL assets with dry-run guards and rate-limit awareness for thread mutations

Fusion Github Review Resolution by the numbers

  • 1,842 all-time installs (skills.sh)
  • +57 installs in the week ending Aug 4, 2026 (Skillselion tracking)
  • Ranked #76 of 1,352 Code Review & Quality skills by installs in the Skillselion catalog
  • Security screen: HIGH risk (skills.sh audit)
  • Data as of Aug 5, 2026 (Skillselion catalog sync)
At a glance

fusion-github-review-resolution capabilities & compatibility

Capabilities
parse pr and review urls · fetch unresolved review threads via github api · evaluate comment correctness against code logic · apply targeted code fixes · create and push commits · post replies to review threads with commit refer · resolve github review threads via graphql/mcp
Works with
github
Use cases
code review · debugging
Platforms
macOS · Linux · Windows
Runs
Runs locally
Pricing
Free
From the docs

What fusion-github-review-resolution says it does

Follow this phase order unless the user explicitly asks for a different sequence: fetch → analyze → fix → validate → push → reply → resolve → verify.
fusion-github-review-resolution/README.md - Instructions section
npx skills add https://github.com/equinor/fusion-skills --skill fusion-github-review-resolution

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs1.8k
repo stars1
Security audit2 / 3 scanners passed
Last updatedAugust 4, 2026
Repositoryequinor/fusion-skills

What it does

Resolve GitHub PR review threads end-to-end by evaluating comment validity, applying fixes, replying with rationale, and closing threads.

Who is it for?

PRs in 'changes requested' state; unresolved inline review threads; iterative feedback cycles where reviewers specify line-level fixes.

Skip if: Read-only branches; feedback summaries without code changes; PRs with no unresolved threads; new PR creation.

When should I use this skill?

User provides PR or review URL with unresolved threads, or explicitly requests review comment resolution or closure of open review conversations.

What you get

A PR with unresolved review comments becomes one with addressed feedback, documented replies, and closed review threads, ready for re-review or merge.

  • Completed review-resolution-checklist.md with all comments evaluated and decisions logged
  • Commits addressing valid review feedback
  • GitHub thread replies (one per comment) posted and visible in PR

By the numbers

  • Skill targets first 100 review threads and first 100 comments per thread when using bundled fetch script
  • Each thread requires 1 reply mutation + 1 resolve mutation (2 GraphQL calls per thread at 5 points each)

Files

SKILL.mdMarkdownGitHub ↗

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/<owner>/<repo>/pull/<number>#pullrequestreview-<id>
  • https://github.com/<owner>/<repo>/pull/<number> (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

  • No unresolved review comments exist
  • Request is only to summarize or describe feedback without code changes
  • All targeted threads are already resolved or outdated and acknowledged
  • 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 (e.g. pullrequestreview-<id>)
  • branch/worktree decision
  • required validation commands for the repository
When a review URL is provided (github.com/<owner>/<repo>/pull/<number>#pullrequestreview-<id>),
auto-extract owner, repo, PR number, and review id from it.
Only branch/worktree choice and validation commands still need confirming.

Optional:

  • linked issue reference (e.g. 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.

1. Ask whether to use a dedicated git worktree

  • Ask this before any other workflow questions.
  • If yes, use/create the worktree and continue there.

2. Gather unresolved comments and create working tracker

  • If a review URL with #pullrequestreview-<id> 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.

3. 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.

4. 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.

5. Push once after all fixes

  • After all comment-related commits are created, push branch updates once.

6. Reply and resolve each review comment

  • Before any thread mutation, prefer structured tooling in this order:

1. dedicated GitHub MCP review-thread reply/resolve tools exposed in the current client session, 2. the bundled GraphQL assets or bundled scripts/resolve-review-comments.sh, 3. 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:

1. 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. 2. 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".

7. 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.

8. 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.

9. 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 <commit>: <what changed>."

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 actionPreferred toolNotes
Request reviewer / update PR metadatamcp_github_update_pull_requestWorks for collaborator reviewers and standard PR updates.
Create or submit PR reviewmcp_github_pull_request_review_writeHandles pending review lifecycle actions.
Add general PR commentmcp_github_add_issue_commentAdds issue-style comment to PR conversation, not inline thread reply.
List review threads and commentsassets/pull-request-review-threads.graphqlUse with gh api graphql -f query=@assets/pull-request-review-threads.graphql for thread-level context.
Count unresolved threads for specific review idassets/unresolved-thread-count-for-review.graphqlPost-process response (for example with jq) to filter by review id and unresolved state.
Reply to a review threadDedicated MCP review-thread reply tool, otherwise assets/add-pull-request-review-thread-reply.graphqlPrefer the MCP tool when available; otherwise use the bundled thread-scoped mutation instead of ad hoc scripts.
Resolve a review threadDedicated MCP review-thread resolve tool, otherwise assets/resolve-review-thread.graphqlUse 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.graphqlUseful 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.

Related skills

Forks & variants (1)

Fusion Github Review Resolution has 1 known copy in the catalog totaling 2 installs. They canonicalize to this original listing.

How it compares

Pick fusion-github-review-resolution when you need programmatic thread resolution with GraphQL replies, not just listing open comments.

FAQ

Should I use a git worktree?

The skill asks this first. Use a worktree if you need isolation from your main branch; otherwise a direct checkout works. The skill supports both.

What if a review comment is incorrect or outdated?

The skill evaluates each comment against current code. If incorrect, it posts a reply explaining why no code change was made, with evidence, instead of creating churn.

Can I resolve threads without posting a reply?

No. The skill enforces that a reply is posted first, then the thread is resolved immediately after. Never one without the other.

Is Fusion Github Review Resolution safe to install?

skills.sh reports 2 of 3 security scanners passed. Review the Security Audits panel on this page before installing in production.

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.