What happens
Switching the audience toggle on an answer changes almost nothing on screen. Nearly every block is shared, and the one or two blocks written for a particular reader are a few sentences at the bottom that look exactly like the blocks above them.
A reader who switches from one audience to another sees the same page and concludes the toggle is decorative.
Why the mechanism produces this
The contract in packages/core/skills/ask/SKILL.md tells the skill to leave audiences empty on everything except a short closing implication block, and visibleBlocks in packages/studio/src/lib/blocks/audience.ts filters on exactly that field. So the toggle can only ever hide the closing paragraph, which is the smallest part of the answer.
That default is right in one direction: a conclusion belongs to whoever asked, and duplicating it per reader would be padding. It is wrong in the other: the parts that genuinely read differently per reader are not marked as such.
Three candidates for parts that could differ and currently do not:
- Evidence depth.
AudienceDescriptor.evidenceDetail already exists and Ask already passes it down. A business reader seeing file paths and line numbers, or an engineering reader seeing a source named only by title, is a real difference the data supports today.
- Findings. A conflict has two sides, and which side a reader needs first is not the same for everyone.
show_finding has no way to say so.
- Ordering. The blocks arrive in one order and every reader gets that order. What matters most is not the same thing for each of them.
What to decide
Whether the audience axis stays a filter over whole blocks, or becomes something a block can vary along. The second is more work and touches the block schema, so it is worth deciding before adding more render calls.
A cheaper first move, if the filter stays: measure the actual difference. If switching reader changes fewer than N blocks on a real answer, the surface knows the toggle is currently doing nothing, and can say so rather than presenting an inert control.
Not this issue
Highlighting the reader's own section is already done: BlockCanvas gives an audience-addressed block a tinted panel and a rule, and BlockOutline gives its index entry weight. That makes the existing difference visible. It does not make the difference larger, which is what this issue is about.
What happens
Switching the audience toggle on an answer changes almost nothing on screen. Nearly every block is shared, and the one or two blocks written for a particular reader are a few sentences at the bottom that look exactly like the blocks above them.
A reader who switches from one audience to another sees the same page and concludes the toggle is decorative.
Why the mechanism produces this
The contract in
packages/core/skills/ask/SKILL.mdtells the skill to leaveaudiencesempty on everything except a short closing implication block, andvisibleBlocksinpackages/studio/src/lib/blocks/audience.tsfilters on exactly that field. So the toggle can only ever hide the closing paragraph, which is the smallest part of the answer.That default is right in one direction: a conclusion belongs to whoever asked, and duplicating it per reader would be padding. It is wrong in the other: the parts that genuinely read differently per reader are not marked as such.
Three candidates for parts that could differ and currently do not:
AudienceDescriptor.evidenceDetailalready exists and Ask already passes it down. A business reader seeing file paths and line numbers, or an engineering reader seeing a source named only by title, is a real difference the data supports today.show_findinghas no way to say so.What to decide
Whether the audience axis stays a filter over whole blocks, or becomes something a block can vary along. The second is more work and touches the block schema, so it is worth deciding before adding more render calls.
A cheaper first move, if the filter stays: measure the actual difference. If switching reader changes fewer than N blocks on a real answer, the surface knows the toggle is currently doing nothing, and can say so rather than presenting an inert control.
Not this issue
Highlighting the reader's own section is already done:
BlockCanvasgives an audience-addressed block a tinted panel and a rule, andBlockOutlinegives its index entry weight. That makes the existing difference visible. It does not make the difference larger, which is what this issue is about.