# Socratic Question Trees

> Six domain-specific question trees for --socratic mode in /zerg:brainstorm. Each tree uses branch IDs (Q1, Q2a, Q2b, etc.) to link options to follow-up questions.

- Skill: `tools-only/socratic-question-trees` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add tools-only/socratic-question-trees`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tools-only/socratic-question-trees/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: tools-only (https://skillmd.com/u/tools-only)
- Updated: 2026-09-29
- Page: https://skillmd.com/skills/tools-only/socratic-question-trees

---

# Socratic Question Trees

Six domain-specific question trees for `--socratic` mode in `/zerg:brainstorm`.
Each tree uses branch IDs (Q1, Q2a, Q2b, etc.) to link options to follow-up questions.

---

### Domain: Auth & Authorization
Keywords: auth, login, session, jwt, oauth, password, token, 2fa

**Q1**: Who are your users and how will they authenticate?
  - a) Internal employees — corporate SSO/LDAP integration likely required -> Q2a
  - b) Public consumers — self-registration with email/social login -> Q2b
  - c) API clients (machine-to-machine) — service accounts with key-based auth -> Q2c
  (Other -> LLM follow-up)

**Q2a**: What identity provider will you federate with?
  - a) Active Directory / LDAP — on-prem directory, SAML or OIDC bridge needed -> Q3a
  - b) Okta / Auth0 / Azure AD — managed IdP, faster setup but vendor lock-in -> Q3a
  - c) Custom internal IdP — full control but high maintenance burden -> Q3b
  (Other -> LLM follow-up)

**Q2b**: How should sessions be managed after login?
  - a) Stateless JWT — scalable but harder to revoke mid-session -> Q3a
  - b) Server-side sessions (Redis/DB) — easy revocation but adds infra dependency -> Q3a
  - c) Short-lived tokens + refresh tokens — balanced security/UX trade-off -> Q3b
  (Other -> LLM follow-up)

**Q2c**: What credential type will API clients use?
  - a) API keys — simple but no built-in expiration or scoping -> Q3b
  - b) OAuth2 client credentials — standard, supports scopes and rotation -> Q3a
  - c) mTLS certificates — strongest auth but complex certificate management -> Q3b
  (Other -> LLM follow-up)

**Q3a**: What authorization model fits your access patterns?
  - a) Role-based (RBAC) — simple, suits most apps with fixed permission sets -> Q4
  - b) Attribute-based (ABAC) — flexible, handles complex contextual rules -> Q4
  - c) Permission-based (ACL) — granular per-resource control, can get unwieldy -> Q4
  (Other -> LLM follow-up)

**Q3b**: What are your token/key storage and rotation requirements?
  - a) Auto-rotate on schedule — reduces exposure window, needs automation -> Q4
  - b) Manual rotation on demand — simpler but prone to stale credentials -> Q4
  (Other -> LLM follow-up)

**Q4**: What level of multi-factor authentication is needed?
  - a) None — acceptable for low-risk internal tools -> END
  - b) Optional MFA (TOTP/SMS) — user choice, improves security posture -> Q5
  - c) Mandatory MFA for all users — strongest protection, higher onboarding friction -> Q5
  (Other -> LLM follow-up)

**Q5**: How will you handle account recovery when MFA is lost?
  - a) Backup codes generated at enrollment — self-service, must be stored securely -> END
  - b) Admin-assisted reset — secure but creates support burden -> END
  - c) Secondary verification (email/phone) — convenient but weaker than primary MFA -> END
  (Other -> LLM follow-up)

---

### Domain: API Design
Keywords: api, rest, graphql, endpoint, route, http

**Q1**: What API style best fits your client needs?
  - a) REST — well-understood, strong caching, best for CRUD-heavy services -> Q2a
  - b) GraphQL — flexible queries, reduces over-fetching, adds schema complexity -> Q2b
  - c) gRPC — high performance, strong typing, best for internal service-to-service -> Q2c
  (Other -> LLM follow-up)

**Q2a**: How will you version your REST API?
  - a) URL path versioning (/v1/) — explicit, easy to route, clutters URLs -> Q3a
  - b) Header-based versioning — clean URLs but less discoverable -> Q3a
  - c) No versioning (additive changes only) — simplest but limits breaking changes -> Q3a
  (Other -> LLM follow-up)

**Q2b**: How will you manage your GraphQL schema evolution?
  - a) Deprecation annotations + sunset period — gradual, client-friendly -> Q3a
  - b) Schema stitching / federation — scales across teams but adds orchestration -> Q3b
  - c) Monolithic schema with strict review — simple governance, bottleneck risk -> Q3a
  (Other -> LLM follow-up)

**Q2c**: How will clients consume your gRPC service?
  - a) Direct gRPC clients (internal only) — fastest, requires proto sharing -> Q3b
  - b) gRPC-Web gateway for browser clients — broader reach, adds proxy layer -> Q3a
  - c) REST transcoding via gRPC-Gateway — dual protocol support, extra maintenance -> Q3a
  (Other -> LLM follow-up)

**Q3a**: How should the API handle pagination for list endpoints?
  - a) Cursor-based — stable for real-time data, no page-skip support -> Q4
  - b) Offset/limit — simple, allows page jumping, inconsistent under writes -> Q4
  - c) Keyset pagination — performant at scale, requires sortable key -> Q4
  (Other -> LLM follow-up)

**Q3b**: How will you authenticate API requests?
  - a) Bearer tokens (JWT/opaque) — stateless verification, standard OAuth2 flow -> Q4
  - b) API keys in headers — simple for server-to-server, no user context -> Q4
  - c) Session cookies — works for same-origin browser clients, needs CSRF protection -> Q4
  (Other -> LLM follow-up)

**Q4**: What error response strategy will you use?
  - a) RFC 7807 Problem Details — standardized, machine-parseable, widely supported -> Q5
  - b) Custom error envelope — full control but clients must learn your format -> Q5
  - c) HTTP status codes + plain message — minimal, sufficient for simple APIs -> Q5
  (Other -> LLM follow-up)

**Q5**: What rate limiting strategy protects your API?
  - a) Fixed window per API key — simple to implement, allows burst at window edges -> END
  - b) Sliding window / token bucket — smoother traffic, slightly more complex -> END
  - c) Tiered limits by plan/role — monetization-friendly, requires plan management -> END
  (Other -> LLM follow-up)

---

### Domain: Data Pipeline
Keywords: data, pipeline, etl, streaming, batch, warehouse, analytics

**Q1**: What is your data processing latency requirement?
  - a) Batch (hourly/daily) — simpler ops, higher latency, cost-efficient -> Q2a
  - b) Near real-time (seconds to minutes) — micro-batch or streaming with windowing -> Q2b
  - c) Real-time (sub-second) — event streaming, highest infra complexity -> Q2b
  (Other -> LLM follow-up)

**Q2a**: What are your primary data sources?
  - a) Relational databases (CDC/dumps) — structured, use change data capture for freshness -> Q3a
  - b) Flat files (CSV/JSON/Parquet) — simple ingestion, schema drift risk -> Q3a
  - c) Third-party APIs — rate-limited, needs retry/backoff logic -> Q3b
  (Other -> LLM follow-up)

**Q2b**: What streaming platform will you use?
  - a) Kafka — highest throughput, strong ecosystem, operational overhead -> Q3a
  - b) Cloud-managed (Kinesis/Pub-Sub/EventHub) — less ops, vendor-coupled -> Q3a
  - c) Redis Streams — lightweight, good for moderate volume, limited durability -> Q3b
  (Other -> LLM follow-up)

**Q3a**: Where does transformation logic run?
  - a) SQL-based (dbt/Spark SQL) — accessible to analysts, limited for complex logic -> Q4
  - b) Python/Scala (Spark/Beam) — full flexibility, requires engineering skills -> Q4
  - c) ELT in warehouse (transform after load) — leverages warehouse compute, simpler pipeline -> Q4
  (Other -> LLM follow-up)

**Q3b**: How will you handle schema evolution and data quality?
  - a) Schema registry with compatibility checks — prevents breaking changes upstream -> Q4
  - b) Contract testing between producer/consumer — catches drift early, needs CI integration -> Q4
  - c) Validate on read (schema-on-read) — flexible but pushes errors downstream -> Q4
  (Other -> LLM follow-up)

**Q4**: Where will processed data land?
  - a) Cloud data warehouse (BigQuery/Snowflake/Redshift) — optimized for analytics queries -> Q5
  - b) Data lake (S3/GCS + catalog) — cheapest storage, requires query engine on top -> Q5
  - c) Operational database (Postgres/Mongo) — low-latency reads, not ideal for heavy analytics -> Q5
  (Other -> LLM follow-up)

**Q5**: How will you monitor pipeline health?
  - a) Row count + freshness checks (dbt tests / Great Expectations) — catches data issues -> END
  - b) End-to-end latency + throughput metrics (Datadog/Prometheus) — catches infra issues -> END
  - c) Data observability platform (Monte Carlo/Soda) — unified view, additional cost -> END
  (Other -> LLM follow-up)

---

### Domain: UI/Frontend
Keywords: ui, frontend, react, vue, angular, component, css, design

**Q1**: What framework fits your team and project needs?
  - a) React — largest ecosystem, flexible architecture, steeper learning curve -> Q2a
  - b) Vue — gentle learning curve, opinionated defaults, smaller talent pool -> Q2a
  - c) Angular — batteries-included, strong typing, heavier bundle baseline -> Q2a
  - d) No framework (vanilla/HTMX) — minimal JS, fast initial load, limited interactivity -> Q2b
  (Other -> LLM follow-up)

**Q2a**: What rendering strategy serves your content best?
  - a) Client-side rendering (SPA) — rich interactivity, poor SEO without extra work -> Q3a
  - b) Server-side rendering (Next/Nuxt) — good SEO + fast first paint, server cost -> Q3a
  - c) Static site generation — fastest delivery, only works for content that rarely changes -> Q3b
  - d) Hybrid (per-route choice) — optimal per page, more build complexity -> Q3a
  (Other -> LLM follow-up)

**Q2b**: How will you handle dynamic interactions?
  - a) HTMX / server-rendered partials — progressive enhancement, minimal JS -> Q3b
  - b) Web components — framework-agnostic, encapsulated, limited tooling -> Q3b
  (Other -> LLM follow-up)

**Q3a**: How will you manage client-side state?
  - a) Built-in (useState/Pinia/NgRx) — framework-native, sufficient for most apps -> Q4
  - b) External store (Redux/Zustand/MobX) — predictable, adds boilerplate -> Q4
  - c) Server state library (TanStack Query/SWR) — cache-first, reduces client state -> Q4
  (Other -> LLM follow-up)

**Q3b**: Will you adopt an existing design system or build custom?
  - a) Existing system (MUI/Tailwind/Shadcn) — fast start, customization limits -> Q4
  - b) Custom design system — full brand control, significant upfront investment -> Q4
  (Other -> LLM follow-up)

**Q4**: What are your accessibility requirements?
  - a) WCAG 2.1 AA (standard compliance) — covers most legal/ethical requirements -> Q5
  - b) WCAG 2.1 AAA (strict compliance) — highest standard, constrains design choices -> Q5
  - c) Best-effort (semantic HTML + ARIA basics) — minimum viable, may miss edge cases -> Q5
  (Other -> LLM follow-up)

**Q5**: How will you test the UI?
  - a) Unit + integration (Vitest/Jest + Testing Library) — fast feedback, limited visual coverage -> END
  - b) E2E (Playwright/Cypress) — real browser, slower but catches integration bugs -> END
  - c) Visual regression (Chromatic/Percy) — catches unintended style changes -> END
  (Other -> LLM follow-up)

---

### Domain: Infrastructure
Keywords: infra, deploy, ci, cd, docker, kubernetes, cloud, aws, gcp

**Q1**: Where will your application be hosted?
  - a) Major cloud provider (AWS/GCP/Azure) — full service catalog, learning curve -> Q2a
  - b) PaaS (Vercel/Railway/Fly.io) — minimal ops, limited customization -> Q2b
  - c) Self-hosted / on-prem — full control, full responsibility for everything -> Q2a
  (Other -> LLM follow-up)

**Q2a**: What compute model fits your workload?
  - a) Containers (ECS/GKE/AKS) — portable, consistent environments, orchestration overhead -> Q3a
  - b) Serverless functions (Lambda/Cloud Functions) — auto-scale to zero, cold start latency -> Q3b
  - c) VMs (EC2/Compute Engine) — maximum control, manual scaling and patching -> Q3a
  (Other -> LLM follow-up)

**Q2b**: What is your deployment trigger?
  - a) Git push to main — simple, fast iteration, needs strong branch protection -> Q3b
  - b) Manual promotion through environments — controlled, slower, audit-friendly -> Q3a
  (Other -> LLM follow-up)

**Q3a**: What does your CI/CD pipeline need to include?
  - a) Build + test + deploy (standard) — covers basics, sufficient for most teams -> Q4
  - b) Build + test + security scan + deploy + smoke test — comprehensive, slower pipeline -> Q4
  - c) Build + test + canary deploy + auto-rollback — progressive delivery, complex setup -> Q4
  (Other -> LLM follow-up)

**Q3b**: How will you handle environment configuration?
  - a) Environment variables (12-factor) — simple, works everywhere, no versioning -> Q4
  - b) Secrets manager (Vault/AWS SM/GCP SM) — audited, rotatable, adds dependency -> Q4
  - c) Config files per environment — explicit, versioned, risk of secret leakage in repo -> Q4
  (Other -> LLM follow-up)

**Q4**: What monitoring and observability do you need?
  - a) Metrics + logs (Prometheus/Grafana/ELK) — standard stack, self-hosted or managed -> Q5
  - b) Full observability (metrics + logs + traces) — deeper insight, higher cost/complexity -> Q5
  - c) Managed APM (Datadog/New Relic) — turnkey, expensive at scale -> Q5
  (Other -> LLM follow-up)

**Q5**: What is your scaling and disaster recovery strategy?
  - a) Horizontal auto-scaling + multi-AZ — handles load spikes, resilient to AZ failure -> END
  - b) Multi-region active-passive — disaster recovery, adds data replication complexity -> END
  - c) Multi-region active-active — highest availability, hardest to implement correctly -> END
  (Other -> LLM follow-up)

---

### Domain: General
Keywords: (fallback for unmatched domains)

**Q1**: What type of problem are you solving?
  - a) Building a new product/feature — greenfield, maximum design freedom -> Q2a
  - b) Improving an existing system — must work within current constraints -> Q2b
  - c) Migrating or replacing a system — continuity critical, risk management key -> Q2b
  (Other -> LLM follow-up)

**Q2a**: What is the scope of this project?
  - a) Single service or module — focused, can ship independently -> Q3a
  - b) Multi-service system — needs coordination, API contracts, shared infra -> Q3a
  - c) Full platform / product — large scope, phased delivery recommended -> Q3b
  (Other -> LLM follow-up)

**Q2b**: What are the biggest pain points with the current system?
  - a) Performance / scalability — need measurement before optimization -> Q3a
  - b) Maintainability / tech debt — refactoring scope must be bounded -> Q3a
  - c) Missing features / capability gaps — prioritization framework needed -> Q3b
  (Other -> LLM follow-up)

**Q3a**: Who are the primary users of this system?
  - a) Internal team members — known users, direct feedback loop -> Q4
  - b) External customers (B2C) — large scale, UX-critical, support cost matters -> Q4
  - c) Business clients (B2B) — SLA-driven, integration requirements, enterprise features -> Q4
  (Other -> LLM follow-up)

**Q3b**: How will you prioritize what to build first?
  - a) User impact (highest value first) — customer-centric, needs usage data -> Q4
  - b) Technical risk (hardest problems first) — de-risks early, delays visible progress -> Q4
  - c) Dependencies (unblock others first) — optimizes team throughput -> Q4
  (Other -> LLM follow-up)

**Q4**: What are your primary constraints?
  - a) Timeline (fixed deadline) — scope must flex, cut features not corners -> Q5
  - b) Budget (limited resources) — maximize ROI, prefer managed services -> Q5
  - c) Team size / skills — scope to capabilities, plan for learning curve -> Q5
  (Other -> LLM follow-up)

**Q5**: How will you measure success?
  - a) Quantitative metrics (latency, throughput, conversion) — measurable, needs instrumentation -> END
  - b) User satisfaction (NPS, task completion rate) — meaningful, harder to measure -> END
  - c) Business outcomes (revenue, cost reduction) — ultimate measure, lagging indicator -> END
  (Other -> LLM follow-up)