ask-questions-if-underspecified

1# Ask Questions If Underspecified
2 
3## Goal
4 
5Ask 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).
6 
7## Workflow
8 
9### 1) Decide whether the request is underspecified
10 
11Treat a request as underspecified if after exploring how to perform the work, some or all of the following are not clear:
12- Define the objective (what should change vs stay the same)
13- Define "done" (acceptance criteria, examples, edge cases)
14- Define scope (which files/components/users are in/out)
15- Define constraints (compatibility, performance, style, deps, time)
16- Identify environment (language/runtime versions, OS, build/test runner)
17- Clarify safety/reversibility (data migration, rollout/rollback, risk)
18 
19If multiple plausible interpretations exist, assume it is underspecified.
20 
21### 2) Ask must-have questions first (keep it small)
22 
23Ask 1-5 questions in the first pass. Prefer questions that eliminate whole branches of work.
24 
25Make questions easy to answer:
26- Optimize for scannability (short, numbered questions; avoid paragraphs)
27- Offer multiple-choice options when possible
28- 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)
29…