design

Installation
SKILL.md

/claude-db:design

Greenfield engine choice + starter model. This is module M0 (engine-selection): a recommendation, not a score/claude-db:design never produces the two audit scores and never writes to a database.

$ARGUMENTS = a plain-language description of the project (the data, the access patterns, the scale, any constraints). If it's too thin to choose well, ask 2–3 sharp questions first — or hand off to /claude-db:start for the full guided wizard.

What to do

  1. Walk the M0 decision tree (references/engine-selection-tree.md; see also references/detection-signals.md and data-tiers.md for the paradigm signals): from the access patterns and shape of the data, narrow to a paradigm (relational / document / key-value / wide-column / vector / time-series / graph), then to a concrete engine.
  2. Recommend an engine — and always compare it against the boring default (Postgres for most app workloads). State plainly when the boring default wins (it usually does) and what specific, concrete need would justify reaching for something else. Be honest about lock-in and operational cost; never fabricate prices, latency, throughput, or benchmark numbers — describe trade-offs qualitatively or mark needs_api if a real figure is required.
  3. Hand back a starter data model for the recommended engine — core entities, keys (UUIDv7/ULID/bigint as appropriate, never floats for money, timestamptz/UTC), the obvious relationships/embeddings, and the constraints/indexes a sane first migration would include.
  4. Draw a paradigm-aware diagram with node scripts/gen-diagram.mjs --file <schema> [--paradigm relational|document|key-value|wide-column|graph] (paradigm-aware: ERD for relational, access-pattern map for document, key+GSI sketch for DynamoDB/KV, node/edge for graph).

Format — novice-first, with an expandable technical layer

  • Lead with a plain, novice-friendly explanation: which database, in one sentence, and why — no jargon up front.
  • Then an expandable technical layer: the DDL/collection spec, index choices, key strategy, and the design-rule rationale (which audit modules each choice satisfies, e.g. M2 keys, M4 types, M11 indexing) for the reader who wants depth.
  • Close by offering: "When you have a first schema, run /claude-db:audit to score it on Design & Integrity and Performance & Scale."
Installs
58
GitHub Stars
19
First Seen
Jun 17, 2026
design — hainrixz/claude-db