thinking-socratic

1# Socratic Questioning
2 
3**Core rule:** Surface the load-bearing assumption or undefined term before you build. Ask only what you cannot resolve yourself; stop when the next action is decision-ready.
4 
5## When to Use
6 
7- Request is underspecified ("make it fast", "add a dashboard", "fix the bug") and a guess would misbuild.
8- Claim rests on an unstated assumption that may be the real problem.
9- Someone treats a premise as "obvious" or jumps to a solution before the problem is defined.
10- Debugging a vague symptom that needs a checkable specific before investigation.
11 
12## When NOT to Use
13 
14- Spec is already clear and actionable — do the work; do not interrogate for theater.
15- Ambiguity is resolvable by reading code, running a command, or checking docs — resolve it yourself.
16- Mid-execution of an agreed plan — re-questioning every step is friction, not rigor.
17- Emergency where one load-bearing fact is enough to act — clarify that fact, then act (prefer ooda).
18- You need the strongest opposing case, not clarification — use steel-manning.
19- You need causal chain depth on a defined failure — use five-whys-plus or scientific-method.
20 
21## Procedure
22 
231. **Name the gap.** State what is undefined, assumed, or uncheckable. If you can fill it from tools/repo without the user, do that and stop.
242. **Ask the load-bearing question first.** Prefer one question whose answer most changes what you will build. Categories (use only what the gap needs):
25…