/socratic

name: socratic
description: This skill should be used when the user asks to "build", "design", "scaffold", "architect", or "plan" any system, feature, service, app, agent, pipeline, connector, or tool — especially when the request is short, vague, or underspecified. It should also be used when the user asks to "review this architecture", "what am I missing", "ask me the right questions", "poke holes in this", or requests a design review before implementation. The skill interrogates the design silently across the relevant engineering domains (requirements, frontend, backend, data, API, security, infra, testing, observability, AI/LLM, mobile, product, cost, compliance, maintenance), resolves what the codebase and engineering defaults can answer, and surfaces only the decisions that require the user's authority.

Socratic

Question yourself till you're left with only answers.

A curated bank of 697 questions a senior engineer asks before and during a build, split by domain. **The default mode is self-interrogation, not interviewing the user.** Read the codebase, apply engineering defaults, reason through the relevant questions, and ask the user only for decisions nobody but they can make.

Two modes

**Mode A — Self-interrogation (default).** Ask and answer the relevant questions internally, then show the resulting contract once.

**Mode B — Interactive interview (opt-in).** Ask the user one yes/no question at a time. Enter this mode only when the user asks to be interviewed, walked through the decisions, or questioned one at a time.

If unsure, use Mode A. Silence is not a request to be interviewed.

Mode A — Self-interrogation

1. Build the working domain set dynamically

For every build, include Requirements and Testing. Then inspect both the request and the existing project for domain signals:

| Signal in the request or project | Domain file | |---|---| | UI, page, component, dashboard, form, frontend | `01-frontend.md` | | service, endpoint, job, queue, backend, business logic | `02-backend.md` | | database, schema, storage, persistence, migration, cache | `03-data.md` | | API, SDK, webhook, connector, integration, OAuth | `04-api.md` | | authentication, accounts, payments, secrets, external input, public exposure | `05-security.md` | | deployment, CI/CD, containers, cloud, scaling | `06-infra.md` | | production, unattended work, cron, monitoring | `08-observability.md` | | AI, LLM, agent, prompt, model, RAG, tool use | `09-ai-llm.md` | | mobile, iOS, Android, offline, PWA | `10-mobile.md` | | human-facing workflow, onboarding, errors, CLI | `11-product-ux.md` | | scale, latency, traffic, token or cloud spend | `12-cost-performance.md` | | personal or regulated data, health, finance, minors, licensing | `13-compliance.md` | | maintained, long-lived, or team-owned work | `14-team-maintenance.md` |

Do not stop at the first match. A connector, for example, normally pulls in API, Security, and Testing. If answering one domain reveals another dependency, add that domain and continue until a complete pass reveals no new domains.

2. Load the smallest sufficient base question depth

Keep the user-facing behavior unchanged while controlling context use:

• **Core (default):** For routine, prototype, internal, or moderately scoped work, read the matching files under `questions/core/`. Always include `questions/core/00-requirements.md` and `questions/core/07-testing.md`.
• **Full:** For production systems, external users, public APIs, authentication, money, PII, regulated data, autonomous tools, costly or irreversible actions, or an explicit deep/full/audit request, read the matching complete files directly under `questions/`. Always include the complete Requirements and Testing files.
• **Escalation:** If a core answer exposes a serious security, reliability, compliance, scale, or operational risk, replace that core domain with its complete file before building.

Treat `$socratic lite` or `$socratic quick` as an explicit Core request. Treat `$socratic deep`, `$socratic full`, and `$socratic audit` as explicit Full requests. Never load all fifteen complete files unless the system genuinely spans all fifteen domains.

Questions consume context even when asked silently. Optimize for material risks resolved, not the number of questions processed.

3. Add specialized knowledge packs only when they sharpen the task

Base domain files stay primary. Packs are optional overlays, not replacements.

• Use a pack when the task clearly maps to a specialized body of tradeoffs, failure modes, or heuristics that the generic domain files do not capture well enough. First consult `packs/registry.md` after selecting the base domains.
• Load `packs/<pack>/core.md` after the base domain files. A pack may also provide `full.md`; load it only when the core pack proves insufficient for the decision at hand. Most packs ship core only.
• Prefer zero to two packs per task. Too many packs recreates the same token problem the Core/Full split was added to solve.
• Treat pack content as compact decision support: question, default answer pattern, tradeoffs, anti-patterns, escalation triggers, and verification checks.
• Select a pack by the capability it adds, not by recognising a book title. Its source material is provenance, not the routing rule.
• For pack structure or naming guidance, read `references/knowledge-pack-architecture.md`.

Examples:

• Use `packs/software-design/core.md` when reviewing complexity, module boundaries, interface design, or accidental generality.
• Use `packs/domain-modeling/core.md` when carving a system into boundaries, naming concepts, or deciding what must stay consistent together.
• Use `packs/data-systems/core.md` when reviewing durable state, consistency, queues, retries, migrations, or failure recovery.
• Use `packs/operations/core.md` when the work must survive production — timeouts, retries, load shedding, rollback, or alerting.
• Use `packs/threat-modeling/