buildmoonshot 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.