Meta - questioning about questioning. Question yourself till you're left with only answers.
Socratic is a self-interrogation skill for agentic AI, packaged as a portable Claude and Codex skill or prompt.
It helps an LLM slow down, inspect the task, ask itself the right engineering questions, and only ask the user for the few decisions that actually require human authority.
Two halves work together:
- 697 questions across 15 engineering domains — what a task must resolve
- 60 decision cards in 10 source-backed packs — how experienced engineers resolve it, distilled from Kleppmann, Nygard, Evans, Ousterhout, Feathers, Khorikov, and others
Neither is loaded whole. The agent selects the slice the task actually signals, so a typical run costs about 3,000 tokens.
Not a form. Not a checklist. A lightweight reasoning loop.
Socratic is not a 697-question checklist and it is not an endless reasoning loop. It asks the smallest set of relevant questions needed to reach a solid, evidence-backed answer.
The agent stops expanding its review when the outcome and scope are clear, consequential assumptions are visible, material risks have a mitigation or verification path, no contradiction changes the plan, and the riskiest assumption can be tested proportionately. If the next question would not change the design, risk, cost, authority decision, or verification plan, it is no longer material.
This is the purpose of self-interrogation: let an agent challenge its own plan from several useful directions, satisfy the meaningful uncertainty, and then build. It should never keep thinking merely to consume tokens, nor stop only because a token budget is low.
The agent interviews itself, not you. Point it at a task, and it silently works through the relevant slice of the question bank — reading the codebase where it can, applying sensible engineering defaults where it can't, and only stopping to ask you about the handful of decisions that are genuinely yours to make (budget, vendor, legal risk, an irreversible call).
What you see is a short contract before any code is written:
Domains considered: requirements, data, security, testing, AI/LLM
Self-answered: Postgres over SQLite (existing driver, concurrent writers)
at-least-once delivery; duplicate work is safe here
no PII in the queue, so no encryption-at-rest work
Assumed (flag if wrong): single-region; retries capped at 5
Open questions for you: 1. Is a 30-second worst-case job latency acceptable?
Top risks: retry storm on downstream outage — no circuit breaker yet
Plan: durable enqueue → worker drain → backoff on failure
One question instead of twelve. The other eleven were answered from your repo.
The loop behind it:
- classify the task
- detect the relevant domains
- load the smallest useful question set
- self-interrogate silently
- surface assumptions, risks, and only necessary open questions
- build
- verify
If you'd rather be interviewed live, ask for it ("interview me," "ask me one at a time") and it switches to a one-yes/no-question-per-turn mode instead. That's opt-in, not the default.
The full question bank contains 697 questions across engineering domains. That is useful for production-grade, high-risk, or audit-style work, but too expensive to load by default for many agentic workflows. So Socratic now has two depths:
Core is the default path. It loads the highest-signal subset of questions first: roughly the top 90 questions that matter most across routine, prototype, internal, and moderately scoped work. Use Core for:
- prototypes
- internal tools
- one-off builds
- medium-scope engineering work
- most day-to-day agentic tasks
Full loads the complete domain files. Use Full for:
- production systems
- public APIs
- authentication
- payments
- PII or regulated data
- autonomous tools
- costly or irreversible actions
- deep audits
- explicit high-risk reviews
The point is not to ask more questions. The point is to ask the most useful questions at the right time without burning unnecessary context.
The whole repository is roughly 29,000 tokens. A normal run loads under a tenth of it. Counted with tiktoken (o200k_base), not estimated:
| What loads | Tokens | When |
|---|---|---|
SKILL.md |
~2,300 | Every run |
| Typical pass — SKILL + 4 core domains | ~2,800 | Most work |
| All 15 core domains | ~4,100 | Broad prototype review |
| Heavy pass — SKILL + 8 full domains + 1 pack | ~10,900 | Production, money, PII |
| Entire repository | ~29,000 | Never |
For scale: the median SKILL.md across Anthropic's 31 officially published skills is 2,255 tokens. Socratic's entry point is the same size as a first-party skill — the depth lives in files that stay on disk until the task calls for them.
The Core/Full split is worth 7.5×. All fifteen compact domain files together are 1,804 tokens; the fifteen complete ones are 13,599. Core files average about 120 tokens each, so even a maximal compact pass costs less than the skill's own instructions.
questions/ and packs/ have different jobs:
- Questions provide coverage: they identify the concerns a task must resolve across requirements, security, data, testing, and other domains.
- Packs provide depth: they add compact, source-backed reasoning for a specialist decision area after the relevant questions have been selected.
Neither replaces the other. A great book does not cover every product, security, testing, or operational concern; a broad question bank does not contain every hard-won systems-design tradeoff.
Ten packs ship today, each a handful of decision cards rather than a summary. packs/registry.md routes between them:
| Pack | Depth it adds | Source |
|---|---|---|
software-design |
complexity, interfaces, accidental generality | A Philosophy of Software Design |
domain-modeling |
boundaries, aggregates, ubiquitous language | Domain-Driven Design |
data-systems |
distributed data, consistency, migrations | Designing Data-Intensive Applications |
operations |
timeouts, retries, load shedding, rollback, alerting | Release It!, Google SRE |
threat-modeling |
trust boundaries, abuse paths, mitigations | Threat Modeling, Security Engineering |
ai-engineering |
LLM evals, retrieval, tools, serving cost | AI Engineering |
agent-design |
agent boundaries, tool permissions, verification | 34 shipped agents (empirical) |
legacy-change |
seams, characterization tests, incremental replacement | Working Effectively with Legacy Code, Refactoring |
testing-design |
what to test, what to mock, why a suite is untrusted | Unit Testing: Principles, Practices, and Patterns |
product-discovery |
whether the thing should exist at all | The Mom Test, Inspired |
For each task, the agent first selects the base domains and Core/Full depth, then reads the compact pack registry and adds zero to two relevant packs only where they sharpen the decision. Pack names describe the capability they add; their book sources are documented as provenance.
Several packs overlap on purpose, so the registry says which to reach for: software-design covers module depth where domain-modeling covers where the boundaries fall; data-systems covers correctness of state under failure where operations covers staying available while failure happens; the Testing domain establishes what must be covered where testing-design decides whether the tests are worth keeping.
agent-design is the one pack that isn't book-derived. Its cards come from structure observed across 34 agents shipped in first-party Claude Code plugins, where seven archetypes recur and the agent that does the work is never the one that verifies it. Structure observed in production beats structure argued from first principles.
Socratic does not copy books into an agent context. It curates their reusable decision patterns into short cards: what to ask, the default answer, the tradeoff, the common mistake, when to escalate, and how to verify the choice. A pack is judged by whether it improves a real implementation decision — never by how much of the book it covers.
| Domain | Questions | File |
|---|---|---|
| Requirements & scope | 40 | questions/00-requirements.md |
| Frontend & UI | 46 | questions/01-frontend.md |
| Backend & services | 45 | questions/02-backend.md |
| Data & storage | 53 | questions/03-data.md |
| API design | 48 | questions/04-api.md |
| Security | 59 | questions/05-security.md |
| Infrastructure & DevOps | 46 | questions/06-infra.md |
| Testing & quality | 38 | questions/07-testing.md |
| Observability & ops | 39 | questions/08-observability.md |
| AI / LLM / agents | 70 | questions/09-ai-llm.md |
| Mobile & offline | 41 | questions/10-mobile.md |
| Product & UX | 45 | questions/11-product-ux.md |
| Cost & performance | 42 | questions/12-cost-performance.md |
| Compliance & legal | 42 | questions/13-compliance.md |
| Team & maintenance | 43 | questions/14-team-maintenance.md |
Every file follows the same shape: Priority 1 questions first, then thematic sections, then a Verification block to run after the build.
The domain set isn't chosen once from the initial request — it's built by scanning for signals and can grow mid-build. Requirements and Testing are always in. Everything else gets pulled in when it matches:
| Signal | Domains added |
|---|---|
| UI, dashboard, form | Frontend |
| service, job, queue | Backend |
| database, schema, cache | Data |
| API, SDK, webhook, connector, integration | API |
| auth, payments, secrets, public-facing | Security |
| deploy, CI/CD, cloud, scaling | Infra |
| production, cron, monitoring | Observability |
| AI, LLM, agent, prompt, RAG | AI/LLM |
| mobile, iOS, Android, offline | Mobile |
| anything user-facing | Product/UX |
| scale, latency, high traffic | Cost/Performance |
| personal data, health, EU/CA users | Compliance |
| long-lived, team project | Team/Maintenance |
A "tool with connectors" isn't just an API question — it pulls in API (contract, third-party auth), Security (credential storage per connector, blast radius if one leaks), and Testing (mocking each connector's failure modes) together. If self-answering later reveals a new need — say, a persistent store you didn't expect — the scan re-runs and adds Data mid-task.
mkdir -p ~/.claude/skills
cp -r socratic ~/.claude/skills/Install under $CODEX_HOME/skills; when CODEX_HOME is unset, use ~/.codex/skills:
mkdir -p ~/.codex/skills
cp -r socratic ~/.codex/skills/Invoke explicitly with $socratic, or let it trigger implicitly when your request matches.
Paste PROMPT.md into the system prompt of any LLM — ChatGPT, Gemini, a local model, your own agent framework. Self-contained, no file dependencies.
For an always-on prompt with minimal overhead, use PROMPT_LITE.md.
Scan request + codebase → build working domain set (dynamic, can grow mid-build)
↓
Self-answer every question: read codebase → apply engineering default → escalate only if it's a business decision
↓
Emit contract once: domains / highlights / assumed / open questions (0-3 ideally) / risks / plan
↓
Ask the (few) open questions, if any — batched
↓
Build
↓
Run Verification for every domain in the final set, including ones added mid-build
- Self-answer by default. The bank exists so the agent has more engineering perspective, not so the user fills out a form.
- Read before assuming; assume before asking. Escalation to the user is the last resort, reserved for decisions only they can authorize.
- Domain set is dynamic. It's built from signals in the request and code, and can grow as the agent learns more mid-task — not fixed at the first guess.
- Testing runs every time. Not gated behind the user asking for it — any tool/service/script that gets built gets its testing questions and verification pass.
- Keep "Open questions" near zero. A long list of open questions means engineering decisions got escalated that shouldn't have been.
- Interactive mode is opt-in, for when a user explicitly wants to be walked through it live.
Add a domain by dropping questions/15-yourdomain.md in, following the existing shape (Priority 1 → sections → Verification), then add a row to the signal table in SKILL.md and PROMPT.md so it gets picked up dynamically.
For source-backed specialist knowledge, add a pack under packs/<name>/core.md and optionally packs/<name>/full.md. Keep packs compact and decision-shaped rather than writing long summaries.
MIT — see LICENSE. Use it, fork it, ship it.
PRs welcome, especially:
- Domains not covered (embedded, games, blockchain, hardware, accessibility-in-depth)
- Questions that came from a real incident — those are the good ones
- Better signal words for dynamic domain detection