Ask dont assume
Skill buildmoonshot/skillpacks/skills/engineering/beginner/ask-dont-assume
A beginner-to-expert curriculum of drop-in skills for Claude Code, Codex, and any coding agent. Copy-paste ready, tested, not a link farm.
npx -y skills add buildmoonshot/skillpacks --skill ask-dont-assumeAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
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.
SKILL.md
1.8 KB, as published. Nobody here has run it
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.