address-review

Handle the review comments on a PR the right way: convergent comments get applied, divergent comments get a human decision. This is the wired form of /continue step 11 ("read the comments, address what you can, ask the developer about ambiguous requests, do not auto-merge"), and it implements the discipline in Human Review in an AI Workflow.

It is reviewer-agnostic (every reviewer, human or bot — CodeRabbit, Copilot, a teammate) and it classifies before acting instead of applying everything. The danger of applying everything is a divergent comment — a disagreement about the approach — being silently applied as if it were a fix. This skill exists to keep that line bright. It is the single path for responding to a PR review: the bulk "just apply the bot's suggestions" case is the fast path below, not a separate skill.

Requires the GitHub MCP. If it isn't connected, say so and stop — do not fall back to scraping the PR page or the gh CLI for fetch.

The core distinction

	Convergent	Divergent
What	A bounded correction with one clear right answer.	A challenge to the approach / design — a decision, not a fix.
Signals	"rename", "extract", "handle the null case", "add a test", "typo", a suggestion block.	"I'm not sure I agree", "why X and not Y", "should we even", "this approach feels wrong", anything that changes the design rather than a line.
Action	Draft the fix → author sign-off → apply → reply "applied".	Never apply. Escalate to the author as a question → human decides → reply on the reviewer's thread with the decision + rationale.

When uncertain, classify as divergent. Escalating a fix is cheap; silently coding away a disagreement is the failure this skill exists to prevent. The conservative bias is deliberate.

Steps

1. Resolve the PR and fetch every comment (orchestrator only)

• Resolve the PR: default to the open PR for the current branch (git branch --show-current → GitHub MCP list_pull_requests with head, state: open); accept an explicit #N. Multi-repo workspace: do this per repo root, skip repos with no open PR.
• Fetch all review feedback, reviewer-agnostic:
  • inline review comments — GitHub MCP pull_request_read with method: get_review_comments (paginate);
  • review summaries / top-level PR comments — method: get_reviews and the issue-comment list.
• Keep every actionable comment from any author (humans and bots — CodeRabbit, Copilot, teammates). Skip pure acknowledgements / praise / already-resolved threads. For each kept comment extract: author, file path (repo-relative → absolute), line/range, comment body, suggested code (if any), thread/comment id (needed to reply).
• If the user named a specific comment/thread, restrict to it.

2. Classify each comment

For each comment, label it convergent | divergent | nit | question:

• convergent — a clear, bounded fix (see table).
• divergent — challenges the approach/design, or you are uncertain (default here).
• nit — non-blocking style preference; treat as convergent but mark non-blocking.
• question — the reviewer is asking, not requesting a change; answer it, and only then decide if a change follows (if it does, re-classify).

Present the classification table to the developer before acting: comment → author → class → planned action. This is the one place the developer can re-bucket anything you misjudged.

3. Convergent path — draft, sign off, apply

For the convergent + nit comments, dispatch one apply-agent per comment in parallel (Agent tool, general-purpose, same turn), each with the full context for a single comment:

Apply this single review comment. Do NOT fetch PRs or comments — everything is below.
- Repo path: <absolute repo root>
- File: <path relative to repo>   Line(s): <line or start-end>
- Comment: <exact body>           Suggested code (if any): <code block or "none">

Apply with a minimal edit (exact string replace). If suggested code is given, use it; else infer.
Preserve project style; do NOT refactor unrelated code. Run the linter on the modified file and
fix any new issues. Return: file path, one-line summary, lint result, or "skipped: <why>".

One comment per agent — never batch. Then run /verify before any push. Get the developer's sign-off on the applied batch before pushing review-response commits — /continue step 11's configurable gate. Do not auto-merge.

4. Divergent path — escalate to a human decision

Do not apply divergent comments. Instead, for each one, present to the author (reviewee) as a question:

Reviewer @<author> raised an approach-level concern on <file:line>:
  "<exact comment>"
This challenges the design, not a single line. Options as I see them:
  (a) keep the current approach because <reason> — I'll reply with the rationale.
  (b) change to <reviewer's suggestion> — I'll apply it.
  (c) something else / discuss further.
What's your call?

Collect the author's decision per comment. Then:

• Author agrees with the reviewer → re-classify as convergent and apply (step 3).
• Author keeps the approach → draft a reply that states the decision and its rationale — never a silent edit, never a silent close. This is the code-reviewer rule generalized: "explain the disagreement inline; future reviewers, human or AI, read those threads to learn."

5. Close the loop — reply on the reviewer's threads

For both paths, post a reply on the reviewer's own thread via GitHub MCP (add_reply_to_pull_request_comment), so the reviewer sees their comment produced an outcome:

• convergent: "Applied in <sha> — <one-line of what changed>."
• divergent → applied: "Agreed — changed the approach to <…> in <sha>."
• divergent → kept: "Keeping the current approach because <rationale>. Open to discussing further."

Show the developer the reply drafts and get sign-off before posting (PR comments are author-attributed communication — the configurable-comment gate applies). Do not mark threads resolved automatically — the human resolves after reviewing.

6. Report

Summarize per repo: comments by class, convergent applied (files + shas), divergent decisions (kept / changed) with the replies posted, anything skipped and why. State the open threads still awaiting the reviewer.

Fast path — an all-bot, all-convergent PR

The common "just apply the bot's accepted suggestions" case — a PR whose only comments are CodeRabbit (or Copilot) nits — needs no ceremony. Classification finds every comment convergent, so the flow collapses to classify → one sign-off → apply the batch → reply, with no per-comment escalation (a bot does not raise a design disagreement). This is the bulk-apply path; it lives here, not in a separate skill, so a bot-only PR and a human-reviewed one go through the same safe door. To restrict a run to one bot's comments, name it (/address-review coderabbit).

Boundaries

• GitHub MCP for fetch + reply — not the gh CLI, not page scraping.
• Divergent comments are never auto-applied. Escalate to the author; a human decides.
• Never silently close or resolve a thread. Every divergent comment gets a human-readable reply stating the decision.
• Reviewer-agnostic. Human and bot comments are treated the same — classification is by content, not by author.
• No unrelated refactors. Convergent edits are minimal and preserve style.
• Doesn't merge. Applies + replies + reports; merge stays a human (or explicitly-configured) action. Honors the Hard Floor and the /continue step-11 configurable gate (sign-off before pushing response commits and before posting replies).
• No worktree isolation needed. This acts on the developer's own active PR branch — it is the current task, not a side-PR — so the session-safety worktree pattern (for skills that create separate branches/PRs) does not apply.

Cross-references

• Human Review in an AI Workflow — the methodology this skill operationalizes (convergent/divergent, escalate-don't-apply).
• code-reviewer — the platform's own pre-merge review; source of the "explain the disagreement inline" rule.
• /pr-review — review a PR (the producing side); this skill is the consuming side (responding to a review).
• /verify — run after applying convergent fixes, before pushing.