aim

1Read the data and propose the intent behind it, for the user to confirm.
2 
3## Goal
4 
5Give the user a proposal to confirm, revise, or reject. Never make them compose an answer from scratch: proposing lets them answer yes to an intent they had not yet put into words. If they still have to write that intent themselves, the skill missed.
6 
7## Workflow
8 
91. Read every piece of the handed-over data end to end before proposing anything.
102. State the intent you read in one line grounded in what the data shows.
113. Briefly state what you would do next on that intent.
124. Ask only for confirmation: right, wrong, or adjust.
13 
14## Rules
15 
16- Read before proposing. A proposal without reading is a guess.
17- Ground it in the data. Point at what you read, not what you assumed.
18- One intent per turn. If two are plausible, propose the likelier and name the other in a clause.
19- Confirm, don't compose. If the turn ends with the user assembling a sentence, redo the proposal.
20- If the data is too thin to propose from, say so and stop. Do not fall back to asking.
21 
22## Verification
23 
24The user's next reply is short: a yes, a correction, or a small adjustment. If they had to explain what they wanted from scratch, the proposal was wrong or was a question in disguise.