Problem statement
When cr posts an inline review-comment finding and a human replies in that thread (e.g. "fixed", "why?", "won't fix because X"), cr does not read or respond. The thread stays open with no acknowledgement, and resolution only happens on a full re-review after the code changes. There is no conversational loop on a comment thread.
Proposed change
Add the ability to respond to replies on cr's own open review-comment threads: detect a new human reply, read it together with the original finding + thread context, post a contextual in-thread reply (acknowledge / clarify / concede), and resolve the conversation once the thread is fully addressed. The GitHub in_reply_to (review-comment replies) and resolveReviewThread plumbing already exists in the gitprovider.
This has two parts:
- Engine (
cr): a "respond to review-comment replies" capability — given a thread (original finding + replies), decide and post a reply, and resolve when done.
- Trigger: today
cr acts on review requests. This needs a new signal — "unresolved replies on threads I authored." A menu-bar watcher (e.g. cr-daemon) could provide it by polling for new thread replies and invoking cr.
Why it matters
Closes the review loop so reviews feel interactive, cuts stale open threads, and lets authors get answers without forcing a full re-review cycle.
Additional context
Could land incrementally: start with resolve-on-acknowledgement (reply says the issue is addressed → resolve), then add generated replies for questions/pushback. Surfaced while dogfooding automated reviews via a reviewer machine account.
Problem statement
When
crposts an inline review-comment finding and a human replies in that thread (e.g. "fixed", "why?", "won't fix because X"),crdoes not read or respond. The thread stays open with no acknowledgement, and resolution only happens on a full re-review after the code changes. There is no conversational loop on a comment thread.Proposed change
Add the ability to respond to replies on
cr's own open review-comment threads: detect a new human reply, read it together with the original finding + thread context, post a contextual in-thread reply (acknowledge / clarify / concede), and resolve the conversation once the thread is fully addressed. The GitHubin_reply_to(review-comment replies) andresolveReviewThreadplumbing already exists in the gitprovider.This has two parts:
cr): a "respond to review-comment replies" capability — given a thread (original finding + replies), decide and post a reply, and resolve when done.cracts on review requests. This needs a new signal — "unresolved replies on threads I authored." A menu-bar watcher (e.g. cr-daemon) could provide it by polling for new thread replies and invokingcr.Why it matters
Closes the review loop so reviews feel interactive, cuts stale open threads, and lets authors get answers without forcing a full re-review cycle.
Additional context
Could land incrementally: start with resolve-on-acknowledgement (reply says the issue is addressed → resolve), then add generated replies for questions/pushback. Surfaced while dogfooding automated reviews via a reviewer machine account.