review-thread-resolution-workflow

Enumerates, answers, and resolves GitHub pull request review threads after CI passes.

1|Updated Jun 9, 2026
One-click install
npx skills add https://github.com/VilnaCRM-Org/claude-plugins --skill review-thread-resolution-workflow-vilnacrm-org
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: review-thread-resolution-workflow
Source: https://github.com/VilnaCRM-Org/claude-plugins/tree/main/plugins/react-frontend-sdlc/skills/review-thread-resolution-workflow
Command: npx skills add https://github.com/VilnaCRM-Org/claude-plugins --skill review-thread-resolution-workflow-vilnacrm-org

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Pull requests with many open review threads from multiple reviewers (CodeRabbit, cubic, qlty, humans) are easy to mishandle: threads get resolved before CI is green, some reviewers' threads are never enumerated, or "will not change" findings are closed without a reasoned reply. This Skill enforces a disciplined workflow so every resolved thread is backed by a verified fix. ## Core Features & Use Cases - Complete thread enumeration: Lists every open thread from every reviewer via the mapped make.pr_comments target or the GitHub CLI, never trusting a single bot's summary. - Recorded outcomes per thread: Each thread gets exactly one outcome — fixed in code, answered with reasoning and left unchanged, or deferred to a filed ticket — before resolution. - CI-gated batch resolution: Threads are resolved in one pass only after the full ci.required_checks set goes terminal and green on the pushed head. - Pagination safety: The bundled listing script refuses to return truncated results when GitHub GraphQL connections exceed the 100-item cap, preventing false "0 unresolved" readings. - Use Case: A pull request accumulates 20 threads from three review bots and two humans; use this Skill to enumerate all of them, fix or answer each one, push, wait for green CI, and resolve the whole set in a single verified pass. ## Quick Start Ask the AI to enumerate all open review threads on pull request 123, reply to or fix each one, and resolve them only after CI passes on the pushed head.

Frequently Asked Questions about review-thread-resolution-workflow

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I resolve many GitHub pull request review threads at once?▼

Enumerate every open thread from every reviewer first, give each thread a recorded outcome (fixed, answered, or deferred), push all changes, wait for CI to go terminal and green on the pushed head, then resolve the whole set in one pass.

When is it safe to resolve a pull request review thread?▼

Resolve only after the thread was read, given an explicit outcome, and the full required CI check suite passed on the pushed head. Resolving while checks are queued turns the resolved state into noise and risks reopening.

Why does the pull request comment listing show fewer threads than expected?▼

GitHub GraphQL connections cap first at 100, and the bundled listing script refuses to page, exiting with an error when hasNextPage is true. A failed or refused listing must never be read as zero unresolved threads; split the pull request or fetch remaining pages manually.

How should I handle a review finding I deliberately will not fix?▼

Post the reasoning as a reply on the thread before resolving it, so the decision is visible and defensible. Never resolve such threads silently, and never satisfy a finding by relaxing a gate or adding an inline suppression directive.

Does this workflow work without a make pr-comments target?▼

Yes. When the profile maps make.pr_comments to null, as in component-library repository shapes, skip the mapped target with a recorded note and enumerate threads directly with the GitHub CLI instead.