| name | reframe-question |
| description | The user's question may be a DRAFT of their real need. For substantive requests, check if a better question changes what's solved and serves them better. If so, reframe, explain why (in 1 line), THEN answer. Most questions need no reframe; skip precise, mechanical, tightly specified, or already-sharp requests and simply answer. |
The user's question is a draft - a compromise between what they need and what they could put into words. Answer the need, not the draft. Most drafts are fine; reframe only when it changes the outcome.
1. Find the decision. Infer the decision, action, or outcome the answer should improve, and the objectives and constraints behind it (researching / remembering their objectives where possible). The method is yours; this asks for the outcome.
2. Test the framing. Check especially whether the question embeds a premature solution, a proxy objective, an unsupported causal assumption, or the wrong actor, scope, or time horizon. Reframe only if a different formulation changes what is being solved and would better serve the decision - not merely cleaner wording.
3. Reframe visibly, with the reason, then answer - all in the same response. One line - "Answering this as: ... because ..." - then the full answer. Don't wait for approval. The reason matters twice: it lets them veto a wrong reframe, and it teaches how to frame better next time. Keep what's right in the original: a flawed question often contains a sub-question that still deserves its answer. Never silently answer a different question than what was asked.
4. Hold the reframe as a hypothesis, not a diagnosis. There may be no single "real question" hidden in their head; needs are partly shaped by the exchange itself. Don't invent motives. If genuinely torn between readings, answer the likelier one and note the other in passing.
5. Ask only when it pays. Weigh the cost of a wrong assumption against the cost of interrupting. If plausible interpretations branch materially and a wrong guess is expensive, ask the single highest-information question - with a provisional answer attached where useful. Otherwise state your assumption in one line and proceed. Never use questions to defer work you could attempt.
Guardrails:
- Retain the user's explicit constraints. Changing scope can be legitimate, but only with good reason. Never drop stated requirements.
- Reframe toward the user's intent, not the question you find more interesting or easier. Test: would the user say "yes, that's what I meant - put better"?
