Ask Clarifying Questions Before Starting Underspecified Work

This skill asks the minimum set of clarifying questions needed to avoid wrong work before implementing, rather than guessing silently or over-questioning a clear request.

Use it when a request has multiple plausible interpretations, or key details are unclear - objective, scope, constraints, environment, or safety and reversibility. Do not use it when the request is already clear, or when a quick, low-risk discovery read (inspecting repo structure, reading relevant config files) can answer the missing details.

Step one decides whether a request is underspecified by checking whether, after exploring how to perform the work, the objective, "done" criteria (acceptance criteria, examples, edge cases), scope, constraints, environment, or safety and reversibility remain unclear - if multiple plausible interpretations exist, the request is treated as underspecified. Step two asks 1-5 must-have questions in the first pass, preferring ones that eliminate whole branches of work, optimized for scannability: short numbered questions, multiple-choice options, clearly marked recommended defaults, a fast-path reply such as "defaults", a low-friction "not sure" option, "need to know" separated from "nice to know" where that reduces friction, and compact reply formats such as "1b 2a 3c" restated in plain language to confirm. Step three pauses before acting: no commands, file edits, or a detailed plan that depends on unknowns until must-have answers arrive, though a clearly labeled, low-risk discovery step that doesn't commit to a direction is fine; if the user explicitly says to proceed without answers, assumptions get stated as a short numbered list and confirmed before work starts. Step four, once answers arrive, restates the requirements in one to three sentences - key constraints plus what success looks like - then starts work. Named anti-patterns: don't ask questions answerable by a quick discovery read, and don't ask open-ended questions when a tight multiple-choice or yes/no would eliminate ambiguity faster.

1) Scope?
a) Minimal change (default)
b) Refactor while touching the area
c) Not sure - use default
2) Compatibility target?
a) Current project defaults (default)
b) Also support older versions: <specify>
c) Not sure - use default

Reply with: defaults (or 1a 2a)

Anyone directing an LLM or agent on ambiguous tasks who wants a small, structured set of clarifying questions asked upfront - eliminating whole branches of wrong work - rather than either guessing silently or over-questioning a request that is already clear.