| name | diffing-finish-review |
| description | Receive a human's diffing review handoff, apply requested edits, answer questions, and keep comment threads synchronized. Use when the user says their review is ready, asks to process diffing comments, or wants the agent to wait for and address review feedback. |
Finish a diffing review
Wait for the human handoff, act only on open comments, and synchronize every response back to diffing.
Receive the handoff
Identify the session that the human handed off before waiting or reading comments. When several reviews are live, run diffing sessions --json, match mode and scope, and select it with diffing sessions use <id>. Then attach/reconnect MCP and call review_session_status; do not assume the newest or currently active session is the one the human reviewed. Once an MCP connection starts/reuses a web session or begins a wait, keep that workflow pinned rather than retargeting it mid-round.
web and tui support the local handoff/comment tools; gh-pr does not have Send to agent, so route that mode to diffing-review's GitHub workflow. If no shell/session manager is available and MCP points at a different session, ask for the intended session to be selected rather than consuming unrelated comments.
In TUI mode, limit native operations to await, list/create/edit/delete comment, reply, and resolve/unresolve. TUI does not expose progress/history, bulk resolve, suggestion application, or reply edit/delete endpoints; use scoped working-tree edits and ordinary reply/resolve instead.
Prefer await_review for a sync local wait (human reviewing now / asked you to wait). Otherwise share the UI URL and park; when they say the review is ready, call await_review once (replays a prior Send-to-agent) or run:
diffing await-review [--timeout <sec>] [--model <name>] [--label <text>] [--agent-id <stable-id>]
A timeout (MCP status: timeout + disposition: park; CLI exit 2) means park — end the turn. Call await again only if the human asked you to keep waiting (at most once more unless they repeat that ask). Do not silent-loop. CLI identity flags let the UI distinguish multiple waiting agents; reuse the same --agent-id for that agent. If blocking tools are unavailable, use list_comments or:
diffing sessions --json
diffing sessions use <reviewed-session-id>
diffing comments --open
diffing comments --format md
after the human confirms the review is ready. Pasted <code-review-comments> XML is the offline fallback.
A released await_review result already includes the handoff XML and structured comments. Act on that payload directly; do not immediately fetch the same threads again. When a refresh is necessary, use list_comments with openOnly: true or diffing comments --open.
Read the root decision and mode before touching files:
| Decision / mode | Behavior |
|---|
comment-only | Do not edit any file. Reply to questions and discuss the general comment. |
changes-requested | Address every clear open change request. |
approved | Address remaining open comments, then continue normally. |
rejected | Do not keep building on the rejected approach; answer or clarify first. |
Process each open comment
- Clear change request: inspect the anchored code and only the surrounding context needed, make the scoped change, verify, reply with what changed, then resolve. Do not refetch the full patch for every thread.
- Question (body is a question, or
severity="question"): reply with the answer; leave open.
- Ambiguous: ask a precise clarification; leave open.
- Nit (
severity="nit"): optional polish — apply when cheap; otherwise reply why not.
- Blocking (
severity="blocking"): treat as must-fix before considering the review done.
- Praise (
severity="praise"): no code change required; optional brief acknowledge.
- Multi-line (
line="A-B"): the range is inclusive on that side — fix the whole span, not only the last line.
- Resolved: do nothing unless the human reopens it (
unresolve_comment / diffing unresolve).
- **```suggestion
fence**: apply viaapply_suggestionMCP orPOST /api/comments//apply-suggestion` when appropriate.
apply_suggestion edits the working tree on the additions side and resolves the thread. Do not use it in comment-only mode. Treat delete_comment, delete_reply, and resolve_all_comments as destructive/bulk actions: use them only when explicitly intended, and never bulk-resolve as a substitute for addressing threads.
MCP:
reply_to_comment · resolve_comment · unresolve_comment
edit_comment · delete_comment · edit_reply · delete_reply
apply_suggestion · resolve_all_comments · report_progress
CLI:
diffing reply <comment-id> --body "..." --model "<model-name>"
diffing resolve <comment-id>
diffing unresolve <comment-id>
diffing comment edit <comment-id> --body "..."
diffing progress --message "Addressing L42…" [--pct 40] [--model M]
Resolve only after a requested change is actually applied. Replies and resolutions update the UI live — send them as each thread completes.
After edits, run focused verification proportionate to the change. If verification fails, keep the thread open and reply with the concrete blocker rather than claiming completion.
Continue the realtime loop
Summarize applied changes and unanswered questions. If the user continues the review, prefer async park until they say ready; use sync await_review / await-review only when they want you to block. Never treat an unchanged timeout as completion, and never silent-loop on timeout.
Optional: get_review_history for multi-round web-session context. History is in memory only, is empty after a server restart, and is not provided by the native TUI API.
