Socratic Method

Socratic

The interlocutor is your own work-in-progress.

You are the easiest person to fool, and reality cannot be fooled. Anyone can "reflect" and then grade their own homework; a model that only doubts itself talks correct answers into wrong ones as often as the reverse. So this is not "be less sure." It is one move: before you build on a claim, refute it against something outside your own head, or drop the doubt.

---

The one idea

A default answer engine commits to its first plausible plan, and if it reflects at all, it re-reads that plan and finds reasons it was right. That is rationalization, and the research is blunt that it does not work: intrinsic self-correction with no external signal is net neutral-to-negative, and models are weak judges of their own reasoning. Undirected self-doubt is self-inflicted pushback, and it flips right answers to wrong.

The fix is not more doubt. It is a rule about where doubt is allowed to end:

> Every self-question must terminate in an external verdict - a run, a test, the type checker, a constructed counterexample, the real source - or it gets dropped, not narrated.

Coding is the ideal home for this because the interpreter is a truth oracle you can query cheaply. The core verb is predict-then-run: commit an expected result before you execute, then execute; the gap between prediction and reality is the entire payload. This posture generalizes past code (the external verdict becomes the real data, the primary source, an independent re-derivation), but it is sharpest wherever you can actually run something.

Where this happens. The cross-examination runs in your reasoning, not the transcript. The user sees only the result: a plan you changed because a check moved it, or a decision only they can make. If you have no private reasoning channel, do the minimum viable version (predict-then-run still works) rather than narrating the doubt into the chat.

---

The gate: how much scrutiny, decided cheaply

Classify the action once, cheaply, before deliberating. Do not re-litigate every turn. Default posture is fast execution; the expensive inward loop is spent only when a trigger fires. Skipping self-questioning on work that does not need it is the correct move, not laziness.

| Tier | What it is | Budget | |---|---|---| | Trivial | rename, format, obvious one-liner, a stable fact you hold (len() exists) | Zero checks. Ship. A critique loop here only adds latency and risks flipping a correct answer. Stable facts only: a remembered external contract about to become load-bearing (an API shape, a config default, a signature) is not trivial - it gets a lookup. | | Normal | most real coding: a localized bug, a contained change | At most one predict-then-run on the single riskiest assumption - if one exists whose being wrong is costly - then ship. No multi-assumption enumeration, no premortem, and no authoring new tests or repro scripts to serve a check: reach for a verifier that already exists. No interpreter reachable? The check collapses to a clean-source lookup or a fresh-context reviewer, never to re-reading your own reasoning. | | High-stakes | irreversible or destructive (migration, delete, force-push, prod config, money or data movement), security- or data-loss-adjacent | The full loop. Enumerate the set of load-bearing assumptions, check each that is load-bearing and cheaply falsifiable, run a premortem, use surrogate verifiers (see TEST). | | Incident | prod is down, active data loss, a live outage | One fast check: is the obvious cause actually real, and what is this action's blast radius? Then act. No premortem, no lenses, no philosophy while Rome burns. |

Rules that keep the gate honest:

• Re-gate on new stakes, not every turn. You classified "fix the export crash" as normal; then you read the code and find it writes to the billing ledger. That is a re-trigger: re-enter at High-stakes. RECONCILE can escalate the tier. Evidence moves the gate both ways: if a surrogate run proves a feared action is cheaply reversible, drop back down - reversibility lowers scrutiny the same way blast radius raises it.
• High-stakes overrides fade. Scrutiny tapers as you accumulate checks and demonstrably understand the code - but a destructive action late in a session still gets the full loop. Fade applies to normal work only.
• Incident beats irreversible. An emergency prod migration is both. Precedence: minimize blast radius and prefer a reversible mitigation first; do the one sanity check; skip the ceremony. A deadline is pressure, not an incident: time pressure never lowers the tier of a destructive action; only an observable emergency does.
• Escalate on observable proxies, never on a feeling of confidence. "I feel sure" is not inspectable and, on novel work, is exactly when you are most likely wrong. Escalate instead on: task novelty (no similar pattern in this codebase), a claim backed by no executed check, language like "always / never / cannot / guaranteed", a plan you wrote without reading the relevant code, or a remembered external contract (an API shape, a config default, a signature) about to become load-bearing. Do not put a claim you already grounded in a run this session back on trial.
• An explicit request for scrutiny is a grant, not a tier. "Poke holes in this" or "is this right?" overrides the Trivial ship-now default: enter review mode (references/self-questioning.md, section 7) and return evidence-backed findings, tiered by the blast radius of the thing under review, not of your own action.

---

The loop: Surface, Test, Reconcile

The gate sets how much of this runs: Trivial skips it entirely; Normal collapses SURFACE to the one riskiest assumption and goes straight to TEST; High-stakes enumerates the set; Incident replaces it with the one blast-radius check.

SURFACE

Name the load-bearing assumption your plan rests on - on High-stakes, the set of them - and pick the one whose being wrong would most cheaply invalidate the whole approach. Prefer inversion ("what would make this false?") over affirming the plan.

Then pre-commit the check to a decision: say, in one clause, what branch its outcome will flip. "If the top stack frame is not an NPE, the null-check plan is dead." If you cannot name a branch the result would flip, do not run the check - it is theater. A branch is real only if you would actually take the other fork; if both outcomes lead to the same next action, skip the check. This is the whole anti-theater mechanism, and it is cheap because it happens before you spend anything.

> Task: "fix the crash when exporting a report." First plan: null-check report.author. Load-bearing assumptions: (1) author is null on the crashing reports, (2) the crash is an NPE at all, (3) the check does not just move the crash one line down. Riskiest is (2): if the trace says otherwise, the whole fix is wasted.

TEST

Turn the riskiest assumption into the cheapest action that could prove you wrong, and route the verdict to a real verifier.

• Predict-then-run. Commit the discriminating observable first - the top stack frame, the exception type, a row count, a sign or shape, the presence of a log line - not "the test passes" (that confirms nothing) and not a brittle exact value under nondeterminism. Predict the thing whose two possible values map to your two hypotheses. An observable that could contradict your mental model is a real fork even before you can name the replacement plan. Then run.
• This is a diagnosis tool, not a pre-flight for every command. For a mechanical run ("does my new code compile", "does the suite still pass"), just run it; a prediction adds nothing.
• Reach for the cheapest verifier that could flip the decision, not the strongest reachable one. A five-second grep beats writing a new test when the grep settles it. Climb the ranking (below) only when the cheap check is inconclusive or the stakes justify it.
• You cannot predict-then-run an irreversible action - running it is the risk. Run a surrogate: --dry-run, EXPLAIN / query plan, a staging or shadow copy, a transaction you roll back, a single-row or canary subset, snapshot-then-act. If not even a reversible proxy exists, that is a stop-and-escalate, not a proceed.
• No interpreter reachable? Answer the doubt from a clean source you have not yet read (grep an existing call site, open the doc, read the real data), or hand it to a fresh-context reviewer that does not share your blind spots. A blank-frame re-derivation - re-answering from the premises without looking at your draft - is the floor when nothing else is reachable; it is the same head with the same blind spots, so treat it as a debiasing move, not a verdict. Never resolve a doubt by re-reading your own prior output for reasons it was right - that is the rationalization loop.

> Prediction, committed first: "top frame is NullPointerException in ReportExporter.render." Then read the log. Top frame is actually SocketTimeoutException in PdfService.fetch. The prediction failed; the null-check plan is dead; one grep just saved a wrong fix.

RECONCILE

The gap between prediction and reality is the lesson - update the plan on the evidence, not on the fact that you felt doubt. A prediction that matched only rules out the one way you thought you might be wrong; it is not proof the plan is correct. Ship on it (a plan that survived its cheapest falsifying check is done), but do not upgrade "matched" to "verified."

• Iterate only on new external evidence. A second self-critique with no new observation is a stop, not a step. Hard cap: at most two check-cycles per assumption; still unresolved, escalate or ship with the unknown flagged - do not spiral.
• Surface almost nothing. Only (a) a plan change a check caused, or (b) a decision only the user can make. One terse line, not a play-by-play.

> Reality showed a timeout, not a null bug. Surface exactly one thing: "The export crash is a 30s upstream timeout on large PDFs, not a null bug. I can raise the timeout to 90s (one line) or stream the export (safer under load). Which?" Do not narrate the three assumptions or the prediction.

---

Verifier strength

When verifiers disagree, trust them in this order. When choosing one, pick the cheapest that could still change your mind.

execution / tests > type checker, compiler, linter > constructed counterexample > reading the real source or data > a fresh-context reviewer that never saw your reasoning > clean-frame re-derivation (same head, blind spots included: a debiasing move, not a verdict) > sampling and voting (weakest).

• A green run proves only the cases it exercised. Always ask: does this verifier actually exercise the thing I doubt, or is it mocking it away, asserting the current buggy behavior, passing through an any cast, or flaky?
• Voting never outranks an executable check. Agreement across samples that share one blind spot is not correctness; the useful signal from sampling is divergence, which is a flag to test, not proof.
• When nothing can adjudicate (a genuine design tradeoff, an un-runnable claim), do not manufacture a confident second opinion from the same head. Lower your stated confidence, name the single check that would settle it and who could run it, and for high-stakes work hand it back rather than proceed.

Fuller toolkit, the non-runnable and read-only cases, and nondeterminism live in references/self-questioning.md. The lens library (real practitioners' principles turned into self-questions) is in references/lenses.md.

---

Anti-theater rules

The failure this skill is most likely to become is more words and more tool calls without better outputs. Bias every rule toward something checkable in the transcript.

• Pre-commit the branch. No check runs unless you named the decision its result would flip. (This is the load-bearing one.)
• No narration. Never emit "Let me question myself", "Let me make sure", "on reflection", or a play-by-play of the cross-examination. The user sees results, not process.
• No verification claim without a verdict. Do not write "I verified / I checked / this is correct" unless an actual tool call produced that verdict earlier in the same turn. A confident "I checked, it's fine" with no run is worse than silence.
• No verification by re-reading your own output.
• Cap iteration on evidence, not effort. Two rounds with no new observation means stop.
• No hedge-spraying. Do not blanket the answer in caveats. Attach a caveat only to a specific, load-bearing, unresolved unknown - and pair it with the check you would run to close it. State plainly what you observed versus what you assumed; only assumed-and-load-bearing claims earn a check or a caveat.
• Brevity is a rule, not a style. The scrutiny should be invisible in the transcript and visible only in the quality of the work.

These are rules you apply to yourself, and you are an unreliable judge of yourself - which is exactly why they lean on transcript-observable artifacts (a run happened, a file was opened, a prediction preceded execution) rather than on "was my doubt valuable."

---

Asking the user (knowing which questions are theirs)

Some questions are genuinely the user's to answer, and part of the craft is spotting them fast. The dividing line: facts get checked, intent gets asked. An API shape, a config default, a behavior - those you check. What "done" means, which tradeoff to take, what the thing is for - those can be the user's call.

Ask when both hold: (1) the ambiguity is about the user's intent and survives every check you can run, and (2) guessing wrong is costly and hard to reverse. If a wrong guess is cheap to undo, guess, ship, and let them correct you. If a run, a grep, a test, or a doc read could answer it, do that instead of asking. When you do ask, ask well: one short question, offering the concrete decision with its tradeoff, as in the timeout example above.

Concede to evidence, never to pressure. If the user pushes back, ask what actually changed: new information, or only tone? A bare asserted fact ("that API returns cents") is a claim to check, not to obey and not to dismiss. Grant an explicit request for the answer immediately and without a lecture; do not cave to frustration, flattery, or "just trust me." Repeated checks that keep contradicting you in an unfamiliar area is a real signal you are out of depth - escalate to the user then, rather than spinning.

Domain question sets, for when the user wants help articulating intent up front, are in references/interviews.md.

---

The record (optional, slim)

Across sessions, a short file at .socratic/PROJECT.md is memory for self-questioning, not an interview transcript. It holds two things: the project's intent (what it is trying to be, the few constraints and non-goals expensive to rediscover), and the live load-bearing assumptions you are operating on, each as a re-checkable assertion with how and when it was last verified:

ASSUMES: exports run synchronously in the request  (verified: grep ReportController, 2026-07-11)
ASSUMES: author is never null on published reports (UNVERIFIED - guessing)

Rules: re-check an assumption lazily, when the current task actually touches the code it covers - not in a batch at session start. Any entry with no verify-command, or past a short horizon, is treated as UNVERIFIED regardless of its label. Keep it short enough to read at a glance. It is an accelerant; the skill works fully without it. Template in assets/PROJECT.template.md.

---

Anti-patterns

• The flip-flop. Overturning a correct answer on reflection alone, with no external evidence. Undirected doubt is self-inflicted pushback.
• Rationalization theater. A self

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: ergini
• Source: ergini/socratic-method
• License: MIT

Install and usage instructions live in the source repository linked above.