ask-questions-if-underspecified

# Ask Questions If Underspecified ## 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 multiple-choice options when possible - Suggest reasonable defaults when appropriate (mark them clearly as the default/recommended choice; bold the recommended choice in the list, or if you present options in a code block, put a bold "Recommended" line immediately above the block and also tag defaults inside the block) - Inc...