Feature hasn't been suggested before.
Describe the enhancement you want to request
The problem
A question tool Option is { label, description }. That's fine for preference questions, but not when the choice is between things that are inherently visual, two layouts, two API shapes, two directory structures, two implementations of the same function.
One line of description can't carry that difference, so the model dumps every variant into its message text before asking, and the prompt then appears below with bare labels like 1. Split 2. Stacked. You have to scroll back up and hold both variants in your head to map the labels onto them. The content and the choice get separated at exactly the moment you need them together and if the message has scrolled off, you're choosing blind.
What I'd like to add
An optional preview on an option: a block of plain monospace text shown beside the option list, tracking whichever option is focused.
Constraints that keep it narrow:
- Optional : an option without one behaves exactly as today. Purely additive.
- Single-select only: with
multiple: true there's no single focused option for the pane to track, so it's ignored.
- Plain monospace, rendered verbatim : no markdown, no HTML, no ANSI. Fence markers stripped if the model wraps the content in a code block.
- Capped and truncated, never an error : a preview is a display affordance and shouldn't be able to fail a tool call.
- Bounds come from the viewport, not the content : see below.
The benefit is that the comparison lives in the prompt instead of above it, so choosing needs neither scrolling nor memory, and the message body stays clean.
Why the bounding matters
Height and width derive from the terminal, never from the content. So the prompt can't grow with preview content, long lines clip instead of wrapping (ASCII alignment survives), the option list doesn't reflow as the selection moves, and narrow terminals fall back to a single column.
This matters because "the question UI outgrew my screen" is already recurring in #11367, #18673, #11014, and #36803 (closed as a duplicate of #11367). Adding content to that prompt without fixing the bound would make it worse, so the two are coupled.
Which layer should this live on?
This is what I'd most like guidance on.
On dev, Question.Option is rendered directly by the question surfaces, so the field goes there.
On the v2 line the question tool lowers into a Form, and toField() maps options through { value, label, description }, a preview would be silently dropped at that line. So on v2 this is two schema changes, Question.Option and Form.Option, plus forwarding in the converter. Arguably Form.Option is the better home anyway, since then every form gets previews rather than just questions.
Which line should a PR target, and does Form.Option seem right?
Prior art
Status
Implemented against the dev schema field, normalization done once at the tool boundary so no renderer has to defend itself, and the pane on the TUI prompt, the run footer, and the web/desktop dock, with tests.
Opening this before sending the PR because CONTRIBUTING.md asks for design review on UI and core features, and because the layering question may change where it belongs. Happy to retarget or drop it.
Feature hasn't been suggested before.
Describe the enhancement you want to request
The problem
A question tool
Optionis{ label, description }. That's fine for preference questions, but not when the choice is between things that are inherently visual, two layouts, two API shapes, two directory structures, two implementations of the same function.One line of description can't carry that difference, so the model dumps every variant into its message text before asking, and the prompt then appears below with bare labels like
1. Split 2. Stacked. You have to scroll back up and hold both variants in your head to map the labels onto them. The content and the choice get separated at exactly the moment you need them together and if the message has scrolled off, you're choosing blind.What I'd like to add
An optional
previewon an option: a block of plain monospace text shown beside the option list, tracking whichever option is focused.Constraints that keep it narrow:
multiple: truethere's no single focused option for the pane to track, so it's ignored.The benefit is that the comparison lives in the prompt instead of above it, so choosing needs neither scrolling nor memory, and the message body stays clean.
Why the bounding matters
Height and width derive from the terminal, never from the content. So the prompt can't grow with preview content, long lines clip instead of wrapping (ASCII alignment survives), the option list doesn't reflow as the selection moves, and narrow terminals fall back to a single column.
This matters because "the question UI outgrew my screen" is already recurring in #11367, #18673, #11014, and #36803 (closed as a duplicate of #11367). Adding content to that prompt without fixing the bound would make it worse, so the two are coupled.
Which layer should this live on?
This is what I'd most like guidance on.
On
dev,Question.Optionis rendered directly by the question surfaces, so the field goes there.On the
v2line the question tool lowers into aForm, andtoField()maps options through{ value, label, description }, apreviewwould be silently dropped at that line. So onv2this is two schema changes,Question.OptionandForm.Option, plus forwarding in the converter. ArguablyForm.Optionis the better home anyway, since then every form gets previews rather than just questions.Which line should a PR target, and does
Form.Optionseem right?Prior art
inputfield to question tool options for inline text input #30028 asks for aninputfield on the sameOptionstruct. Different direction that is capturing a value vs. displaying one, but the same extension point, which suggests{ label, description }is thin.previewprop todialog-selectfor the agent picker, same two-pane shape. The pattern is already arriving in the TUI; that PR usesminHeight: 18with no upper bound, which is the failure mode above.AskUserQuestionhas this exact field, with the same single-select restriction. Not claiming the idea is original.Status
Implemented against the
devschema field, normalization done once at the tool boundary so no renderer has to defend itself, and the pane on the TUI prompt, therunfooter, and the web/desktop dock, with tests.Opening this before sending the PR because CONTRIBUTING.md asks for design review on UI and core features, and because the layering question may change where it belongs. Happy to retarget or drop it.