mcpField
D
design

design

github.com/hainrixzData & databases2270 installsUpdated 6d ago
Repository

About design

The `/claude-db:design` skill recommends a database engine and starter data model for a new project, based on its data and access patterns. It compares the recommendation with Postgres, explains trade-offs, and can scaffold a reversible first migration with `--emit`.

Key features

  1. 01Selects an engine by data paradigm
  2. 02Compares options with Postgres
  3. 03Proposes a starter data model
  4. 04Generates paradigm-aware diagrams
  5. 05Scaffolds reversible migrations with `--emit`

Use cases

  1. 01Choose an engine for a greenfield project
  2. 02Plan initial entities, keys, and constraints
  3. 03Create a first migration from a starter model

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/hainrixz/claude-db --skill design

After installing, type/designin Claude Code to confirm it loaded.

Details

From the project README

/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."

--emit <prisma|drizzle|sql> — scaffold a first migration

After recommending the model (the steps above still run first; --emit never replaces the recommendation), scaffold a reversible first migration for the chosen target:

  • Generate the schema in the requested format — a Prisma schema, a Drizzle schema, or raw SQL DDL — for the recommended starter model.
  • Hand the scaffold to the db-migration-writer agent (via Task) to write it as a reversible migration (forward + down). The writer reuses fix's guards: refuse on a dirty git tree (treat no git repo as writable, backups still go to the plugin data dir), dry-run preview by default, and no-secrets (never write .env/credentials/invented connection strings).
  • For --emit sql specifically, also offer /claude-db:seed to generate FK-aware seed data for the new schema.

Respond in the user's language (EN/ES).

Comments

Markdown supported