resolve-review
Resolve code review
Bring every review item to an evidence-backed disposition and a confirmed reply, or report what prevents it. Evaluate the concern against the code and the intended change. A reviewer can identify a valid problem while proposing the wrong fix. Choose the investigation, implementation, and verification methods that fit the work; the obligations below define what must be established before publication.
Invocation authorizes commits and pushes to the pull request's existing head branch, replies, thread actions, necessary title and description edits, one addressing summary, and a re-review request. Follow repository conventions and write as the addresser's authenticated identity. Keep this work on the existing pull request. Merging, dismissing reviews, and acting as a reviewing app require separate authorization.
Read the repository's docs/agents/issue-tracker.md when present. Use the addressing protocol for feedback identities, the reply shape, disposition and verdict vocabulary, thread state, check evidence, summaries, and forge operations. Read the sections needed for the current action, including its input and failure contracts. Use each operation's documented invocation from the target checkout. Collection, check-run reads, and thread writes have launcher commands using absolute installed paths; their executable bodies need not be loaded into model context. The new-since-inventory command has its own invocation. A non-zero result requires the documented failure handling, never an assumption of success.
1. Inventory
Identify the target pull request before editing, and ask when it is ambiguous. Collect its metadata and all pages of reviews, inline comments, general comments, and thread states using the protocol's collection block. Record the initial head, branch, collection directory, and every feedback item's stable id or comment id. Include human feedback and review-body feedback that adds something beyond its threads. Skip status-only automation messages.
Keep a ledger of each item's concern, prior discussion, disposition, and reply under its stable identity so feedback is neither lost nor answered twice. Apply the protocol's blocking and optional classifications. Report incomplete collection coverage and address only what was fetched. Missing feedback cannot receive a disposition or count as addressed.
2. Address
Make the changes the evidence warrants and prepare one reply per item in the protocol's shape. Follow a user-named implementation skill; otherwise choose the implementation approach. Weigh optional suggestions under the optional-finding default in the protocol's Questions section. Answer questions, explain disagreements, and use needs-info or blocked when the work cannot be settled. Ask a focused question after available evidence fails to answer it, through the session or the pull request as the caller permits.
A finding declined earlier that the original reviewer verdicts not-fixed is disputed. Answer the reviewer's counter-argument; where neither side moves, say it needs a human decision under the protocol's two-round cap.