domains / families / general / thinking-socratic

thinking-socratic

separate

When a request is vague, assumption-laden, or "obvious," ask the few load-bearing questions that expose hidden requirements before building or committing.

When to use

• Request is underspecified ("make it fast", "add a dashboard", "fix the bug") and a guess would misbuild.
• Claim rests on an unstated assumption that may be the real problem.
• Someone treats a premise as "obvious" or jumps to a solution before the problem is defined.
• Debugging a vague symptom that needs a checkable specific before investigation.

When not to use

• Spec is already clear and actionable — do the work; do not interrogate for theater.
• Ambiguity is resolvable by reading code, running a command, or checking docs — resolve it yourself.
• Mid-execution of an agreed plan — re-questioning every step is friction, not rigor.
• Emergency where one load-bearing fact is enough to act — clarify that fact, then act (prefer ooda).
• You need the strongest opposing case, not clarification — use steel-manning.
• You need causal chain depth on a defined failure — use five-whys-plus or scientific-method.

Skill page

Source