-
Notifications
You must be signed in to change notification settings - Fork 8
Description
Problem
Agent comments in Hunk are currently one-way annotations. You can read them, and you can add/remove/list live comments through the session CLI, but you cannot reply inline and have that reply go back to the agent as a prompt.
That makes agent-assisted review feel static instead of conversational.
Current implementation notes
Related shipped work:
- feat: add session control CLI #50 —
feat: add session control CLI - feat: add live session comment lifecycle #53 —
feat: add live session comment lifecycle
Current CLI support is flat:
hunk session comment addhunk session comment listhunk session comment rmhunk session comment clear
The current live comment model also appears to be flat metadata, not a thread model:
src/mcp/types.ts→LiveCommentsrc/core/liveComments.ts
There is no obvious parent/reply id, thread grouping, or transport for "send this reply back to the agent and await a response".
Potentially related foundation work:
- feat: add Hunk notify stream #77 —
feat: add Hunk notify stream
That notify stream may be the right place to route agent prompts and responses.
Desired behavior
A user should be able to reply to an inline agent comment from Hunk, and that reply should be sent back to the coding agent as a prompt. The agent's answer should then come back into the Hunk session as part of the same discussion.
Acceptance criteria
- Hunk exposes a reply affordance for agent comments in the UI and/or session CLI.
- Replies preserve threading context (for example with a parent comment id or thread id).
- A reply can be routed to the connected coding agent as a prompt.
- The agent's response appears back in Hunk without losing the thread context.
- Threaded comments remain understandable in the review stream and in any CLI output.
- Add end-to-end coverage for at least one reply round-trip.
Notes
This likely needs both:
- a thread-aware comment data model, and
- a transport for sending reply text to the agent and receiving the response.
The notify-stream work in #77 looks like a promising building block, but the product-level workflow still needs to be defined and shipped.