About this skill

When engineers face design reviews, incident retrospectives, or new technical concepts, the issue is often not a missing answer but an answer that appears too early: intuition is treated as fact, local experience is treated as a boundary, and the first workable option is treated as optimal. socratic-dialogue addresses this by avoiding direct answers and using structured follow-up questions to break down ideas, test assumptions, request evidence, and explore alternatives.

Problem: Direct Answers Can Bypass Thinking

Unvalidated assumptions: Many judgments come from “we have always done it this way” or “it should be obvious.”
Thin evidence: Conclusions lack logs, data, constraints, or counterexamples.
Missing alternatives: The current plan is examined without comparing simpler implementations or different tradeoffs.
Non-reusable reasoning: After a one-off response, users may still not know how to verify the next step.

How It Works: Four Questions Instead of One Answer

The skill is built around Socratic dialogue. Its stated goal is not to demonstrate knowledge, but to help users externalize their own thinking. The documented commands include:
- socratic clarify: Clarify thinking by turning a vague goal into discussable questions, constraints, and expected outcomes.
- socratic challenge: Challenge assumptions by asking “why is this assumed to be true?” and “what happens if the premise fails?”
- socratic evidence: Find evidence by prompting for logs, data, docs, tests, or real-world constraints.
- socratic explore: Explore alternatives by proposing different plans, counterexamples, edge cases, and tradeoffs.
- socratic full: Run the complete four-step dialogue when a full review is needed.
- socratic help: List available commands.

It emphasizes “acknowledging ignorance,” the “midwife method,” dialectics, and cross-examination: the assistant does not act as an authoritative expert or a teacher lecturing a user, but uses continuous questioning to help the answer emerge from the user’s own reasoning.

Boundaries

This skill is best for deep thinking, solution review, learning concepts, or postmortems. It is less suitable when users only need a one-line answer, standard API usage, a quick error lookup, or urgent operational instructions. Because the dialogue asks users to keep providing context, checking assumptions, and supplying evidence, it may be slower than receiving a direct answer.

Screenshots

Use Cases

Before a design review, use `socratic full` to organize requirements, constraints, assumptions, and alternatives into a review outline.
During an incident postmortem, use `socratic evidence` to ask for logs, metrics, changes, and timelines needed to test root-cause claims.
When learning a concept or paper, use `socratic clarify` to break vague understanding into definitions, limits, examples, and counterexamples.
Before code review, use `socratic challenge` to check implementation assumptions, edge cases, and performance tradeoffs.

Best For

Engineers who need to explain technical decisions, typically asking for assumptions, evidence, and alternatives in a review-ready form.
Instructors preparing courses or internal training, typically asking for question chains that help students reach conclusions by themselves.
Team leads running postmortems, typically asking to avoid premature blame and first gather facts, timelines, and assumption checks.
Students learning programming or mathematics, typically asking to turn “I think I get it” into explainable and verifiable understanding.