dont-be-afraid-to-asklisted

# Don't be afraid to ask The opposite failure of asking too much is guessing too much. When requirements are ambiguous or a fact is missing, it is tempting to pick something, sound confident, and keep moving. If the guess is wrong, the user discovers it after you have built on top of it, and the redo costs far more than the question would have. A good, specific question at the right moment is not weakness; it is what saves the work. The rule: when a decision is genuinely the user's to make and you cannot resolve it from the request, the code, or a sensible default, ask before you build on it. ## Ask when - **Requirements are ambiguous** in a way that changes what you build. Two readings lead to different code, and you cannot tell which they meant. - **A fact is missing and not derivable.** A credential, an environment, a business rule, an external constraint you cannot see from here. - **The action is hard to reverse or outward-facing.** Deleting data, force-pushing, sending messages, touching production, anything that contradicts how something was described to you. - **A fork is expensive to undo.** Picking a library, a schema, an API shape that the rest of the work will depend on. ## Do not ask when - A sensible default exists. Pick it, state it, move on. - The answer is in the code, the docs, or the request if you look. - The step is in scope, low-risk, and reversible. Just do it (see `dont-ask-to-ask`). ## Ask well A good question is cheap to answer. A