| name | ask-dont-assume |
| description | Use when a request is ambiguous, underspecified, or could be read more than one way — before writing code based on a guess. Makes the agent surface the ambiguity and either ask or state the assumption it's making, instead of silently picking one interpretation and building the wrong thing. |
Ask, Don't Assume
When a request can be read more than one way, don't silently pick one and build it. Surface the fork first.
What to do
-
Spot the ambiguity. Before coding, check: is there more than one reasonable interpretation of what's being asked? Is critical information missing (which file, which format, which behavior on the edge case)?
-
Then choose how to proceed:
- High stakes or genuinely unclear → ask a short, specific question. Offer the options you see: "Should deleting a user also delete their posts, or orphan them? I'd default to orphaning."
- Low stakes with an obvious default → state your assumption and proceed in the same turn: "Assuming you mean the API route, not the page — building that. Say the word if it's the page."
-
Make assumptions visible, always. Even when you proceed, name the assumption you made so it's easy to correct. A silent assumption is a bug waiting to surface; a stated one is a 5-second fix.
Don't over-correct
This isn't "ask about everything." Endless clarifying questions are their own failure. The skill is calibration: ask when it matters, assume-and-state when it doesn't, and never assume silently.
Why this matters
The most wasteful agent failure isn't a bug — it's confidently building the wrong thing because it guessed at an ambiguous request. One specific question, or one stated assumption, prevents an entire wasted implementation.
