Respond to PR Review

human-only. Start this only when a human asks for it by name. A review landing in the conversation is not permission to start answering it — the human decides when the response happens, and every item's disposition below is theirs, save the one class of correction step 3 exempts.

The other side of /review-pr-in-worktree. That skill produced a report and stopped; this one answers it — item by item, each one fixed or discussed, never silently skipped — and leaves the PR ready for the next round.

Almost always the review is pasted straight after the invocation, in the shape /review-a-pr-and-report produces: headings down to Should this be merged, ending in yes or no with bullets. Take that paste as the input. It may also arrive as a GitHub review, a comment thread, or a human's own prose — same process, and step 1 says how to get it.

Every item ends in a disposition the human chose — with one exemption, below. Fixed, or discussed to an outcome, or declined with a reason. A finding you disagree with is a discuss, never a quiet skip: the reviewer is another session with its own read of the specs, it can be wrong, and settling that is a conversation rather than a decision you make alone.

The exemption is the factual comment fix. Where the review says a comment asserts something the code contradicts, and reading the code confirms it, there is nothing for the human to decide — make it, push it, and report it as done. Step 3 sets the boundary.

Where the outcome of a discussion lives is the tracker, not the tree — the approval-policy skill owns that, and step 6 is where this flow applies it. It is the half that gets forgotten.

Process

1. Settle what you are answering, and where

Three things before any of it: