Before submitting
Area
apps/web
Problem or use case
Long answers usually have several things in them I want to push back on at once. Today I either paraphrase each point back into the composer, which loses the exact wording I am reacting to, or I send them one at a time. Sending them one at a time is worse than it sounds: each message starts its own turn, so the agent answers my first objection before it has seen the other three, and then re-plans when they arrive.
The mobile app already has the interaction I want, just pointed at diffs. ReviewHighlighterProvider and ReviewCommentComposerSheet let you select a range, attach a note, collect several, and send them together as one message with <review_comment> blocks. There is no equivalent for assistant messages, and nothing at all on web.
Proposed solution
Selecting text inside an assistant message offers an "add note" action. The selection and the note go into a pending list on the composer instead of sending straight away. When you hit send, the pending notes are serialized ahead of whatever else you typed, in the same block format mobile already uses, so nothing has to change on the prompt side.
Same mental model as leaving comments on a PR and then submitting the review.
Why this matters
Multi-point feedback is the normal case for a long answer and right now it is the most awkward thing to express. Batching is also just cheaper. One turn where the agent sees all four objections together beats four turns where it re-plans after each one, and the answer is better because it can weigh the points against each other instead of in isolation.
Smallest useful scope
Web only, assistant messages only, no persistence. Select, note, collect, send. If the thread reloads while notes are still pending, dropping them is fine. No threading, no editing a note after it is sent, no diff integration.
Alternatives considered
Copying the paragraph into the composer by hand with quote markers. It works, but it is slow enough that most of the time I skip it and send something vaguer instead, which gets me a worse answer.
Risks or tradeoffs
Selection inside streamed markdown is the fiddly part, especially across code fences and list items. Anchoring a selection to a message that might still be streaming needs a rule. The simplest version is to only allow notes on completed messages.
Examples or references
#79 asked for this on diffs and became the review flow, so the pattern already exists in the product.
Current implementation: apps/mobile/src/features/review/reviewCommentSelection.ts (ReviewCommentTarget, ReviewInlineComment, ReviewCommentMessageSegment).
Contribution
Before submitting
Area
apps/web
Problem or use case
Long answers usually have several things in them I want to push back on at once. Today I either paraphrase each point back into the composer, which loses the exact wording I am reacting to, or I send them one at a time. Sending them one at a time is worse than it sounds: each message starts its own turn, so the agent answers my first objection before it has seen the other three, and then re-plans when they arrive.
The mobile app already has the interaction I want, just pointed at diffs.
ReviewHighlighterProviderandReviewCommentComposerSheetlet you select a range, attach a note, collect several, and send them together as one message with<review_comment>blocks. There is no equivalent for assistant messages, and nothing at all on web.Proposed solution
Selecting text inside an assistant message offers an "add note" action. The selection and the note go into a pending list on the composer instead of sending straight away. When you hit send, the pending notes are serialized ahead of whatever else you typed, in the same block format mobile already uses, so nothing has to change on the prompt side.
Same mental model as leaving comments on a PR and then submitting the review.
Why this matters
Multi-point feedback is the normal case for a long answer and right now it is the most awkward thing to express. Batching is also just cheaper. One turn where the agent sees all four objections together beats four turns where it re-plans after each one, and the answer is better because it can weigh the points against each other instead of in isolation.
Smallest useful scope
Web only, assistant messages only, no persistence. Select, note, collect, send. If the thread reloads while notes are still pending, dropping them is fine. No threading, no editing a note after it is sent, no diff integration.
Alternatives considered
Copying the paragraph into the composer by hand with quote markers. It works, but it is slow enough that most of the time I skip it and send something vaguer instead, which gets me a worse answer.
Risks or tradeoffs
Selection inside streamed markdown is the fiddly part, especially across code fences and list items. Anchoring a selection to a message that might still be streaming needs a rule. The simplest version is to only allow notes on completed messages.
Examples or references
#79 asked for this on diffs and became the review flow, so the pattern already exists in the product.
Current implementation:
apps/mobile/src/features/review/reviewCommentSelection.ts(ReviewCommentTarget,ReviewInlineComment,ReviewCommentMessageSegment).Contribution