# Thinking Socratic

When a request is vague, assumption-laden, or "obvious," ask the few load-bearing...

- Repository: https://github.com/tjboudreaux/cc-thinking-skills (1690 stars)
- Category: Engineering
- License: MIT
- Last updated: 2026-08-07
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add tjboudreaux/cc-thinking-skills --skill thinking-socratic -g -a claude-code -y`
Codex: `npx skills add tjboudreaux/cc-thinking-skills --skill thinking-socratic -g -a codex -y`
Cursor: `npx skills add tjboudreaux/cc-thinking-skills --skill thinking-socratic -g -a cursor -y`
Gemini CLI: `npx skills add tjboudreaux/cc-thinking-skills --skill thinking-socratic -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add tjboudreaux/cc-thinking-skills`

## Description

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

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Socratic Questioning

**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.

## 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.

## Procedure

The rest: https://github.com/tjboudreaux/cc-thinking-skills/blob/HEAD/skills/thinking-socratic/SKILL.md