ask-questions-if-underspecifiedlisted

# Ask Questions If Underspecified ## When to Use Use this skill when a request has multiple plausible interpretations or key details (objective, scope, constraints, environment, or safety) are unclear. ## When NOT to Use Do not use this skill when the request is already clear, or when a quick, low-risk discovery read can answer the missing details. ## Goal Ask the minimum set of clarifying questions needed to avoid wrong work; do not start implementing until the must-have questions are answered (or the user explicitly approves proceeding with stated assumptions). ## Workflow ### 1) Decide whether the request is underspecified Treat a request as underspecified if after exploring how to perform the work, some or all of the following are not clear: - Define the objective (what should change vs stay the same) - Define "done" (acceptance criteria, examples, edge cases) - Define scope (which files/components/users are in/out) - Define constraints (compatibility, performance, style, deps, time) - Identify environment (language/runtime versions, OS, build/test runner) - Clarify safety/reversibility (data migration, rollout/rollback, risk) If multiple plausible interpretations exist, assume it is underspecified. ### 2) Ask must-have questions first (keep it small) Ask 1-5 questions in the first pass. Prefer questions that eliminate whole branches of work. Make questions easy to answer: - Optimize for scannability (short, numbered questions; avoid paragraphs) - Offer multi