agentsclimarketplace
Sign in

Dbdesign

Skill vanducng/skills/skills/dbdesign

Design and review production database schemas, data models, ERDs, migration plans, and storage patterns. Use for OLTP schema design, OLAP/star-schema modeling, fact/dimension tables, indexes, constraints, partitioning, multi-tenant data models, CSV/JSON-to-table design, schema review, migration risk review, and database design documents across PostgreSQL, MySQL, SQLite/D1, BigQuery, and MongoDB. Does not execute DDL by default.From its SKILL.md

Install
npx -y skills add vanducng/skills --skill dbdesign

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 5 stars5 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
  • runs commandsInstructs the agent to run 1 command, including `dbdocs validate <path/to/schema.dbml>`.

What its file declares

Copied from the file, not written here

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

4.8 KB, 970 tokens by cl100k_base, as published. Nobody here has run it

DB Design

Design database schemas from requirements, existing data, and query patterns. This skill covers modeling decisions and review quality; use vd:miudb or the sqlit CLI to inspect live databases, vd:diagram for ERDs, and vd:cnpg for CloudNativePG provisioning.

Reference Router

Read only what the task needs:

  • references/workflow.md: intake, schema inspection, output format, and approval gates.
  • references/transactional.md: OLTP entities, relationships, constraints, indexes, soft delete, tenancy, and audit columns.
  • references/analytics.md: OLAP/star schema, facts, dimensions, SCD, summaries, and incremental refresh design.
  • references/engine-notes.md: PostgreSQL, MySQL/MariaDB, SQLite/D1, BigQuery, and MongoDB-specific design notes.
  • references/migration-review.md: migration safety, rollout sequencing, backfills, rollback, partitioning, and risk checks.
  • references/design-doc.md: compact database design document template.

Workflow

  1. Identify the database engine and context: new schema, extension of existing schema, analytics model, data import, migration review, or design doc.
  2. Inspect existing schema before proposing changes when a database or repo is available. Use vd:miudb, the sqlit CLI, migrations, ORM models, dbt models, or schema files as source of truth.
  3. Capture requirements before DDL:
    • entities and relationships
    • main reads/writes/reports
    • expected scale and growth
    • tenancy, permissions, privacy, retention, and audit needs
    • consistency requirements and transaction boundaries
  4. Load the relevant references:
    • OLTP or CRUD app -> transactional.md
    • analytics/reporting -> analytics.md
    • engine-specific DDL -> engine-notes.md
    • migration/change review -> migration-review.md
    • design document -> design-doc.md
  5. Propose the model first, then DDL. Do not execute DDL unless the user explicitly asks and the environment is safe.
  6. Explain tradeoffs: normalization vs denormalization, surrogate vs natural keys, JSON vs columns, partitioning, index cost, retention, and operational risk.
  7. Finish with a checklist and open questions. If assumptions remain, label them instead of pretending certainty.

Design Defaults

  • Model the business language first; table names should reflect domain concepts, not UI screens.
  • Prefer boring relational constraints for integrity: primary keys, foreign keys, unique constraints, checks, and NOT NULL.
  • Index from actual query patterns, not from every column.
  • Add comments/descriptions for tables and important columns when the engine supports them.
  • Use exact numeric types for money and measured quantities.
  • Store timestamps consistently; prefer timezone-aware types when the engine supports them.
  • Plan retention and deletion behavior up front, especially for PII and audit logs.
  • Separate operational tables from analytics/reporting models when workloads diverge.
  • Treat schema migrations as production changes: reversible when possible, staged when large, and tested with realistic data.

Validate DBML with dbdocs

When the design uses DBML (you write or edit a .dbml file):

  • Gate: after writing/editing the file, run dbdocs validate <path/to/schema.dbml>. A clean parse (Parse succeeded without errors.) is required before the design is done. dbdocs is the validator (e.g. dbdocs/0.14.0).
  • No apostrophes inside single-quoted notes. note: 'the row''s id' is not valid DBML and fails with Expect a comma ',' - reword to drop the apostrophe ("the id on this row"); triple-quoted '''...''' notes are fine.
  • Avoid reserved/ambiguous words as column names (e.g. index, now) - they can break the parser; document the column in the table Note instead, or quote/rename it.

Hard Rules

  • Do not invent a schema when existing tables might already cover the domain. Inspect first or ask for the schema.
  • Do not execute DDL by default. Present DDL and migration steps for approval.
  • Do not generate irreversible destructive migrations without an explicit warning and safer alternatives.
  • Do not design indexes without naming the query pattern each index serves.
  • Do not put secrets, credentials, or real PII in design docs, examples, PR bodies, or committed files.
  • Do not preserve old source skill names or Claude-specific paths in new work.

What ships with it: 7 files

19.6 KB alongside SKILL.md

agents/

references/

Gives 0 of the 12 instructions most databases sql skills give in 970 tokens

Counted across 609 of the 712 authors here whose files we hold, read 2026-09-06

  • Index all foreign key columnsin 26 of 609
  • Use cursor pagination instead of offsetin 25 of 609, across 20 files
  • Use timestamptz for timestampsin 21 of 609
  • Specify columns instead of using select starin 20 of 609, across 10 files
  • Use parameterized queries for all database interactionsin 20 of 609, across 19 files
  • Use Enum for categorical datain 17 of 609, across 7 files
  • Order by frequently filtered columnsin 17 of 609, across 7 files
  • Batch data insertsin 17 of 609, across 7 files
  • Use expand-contract pattern for schema changesin 17 of 609
  • Use materialized views for real-time aggregationsin 16 of 609, across 6 files
  • Partition tables by timein 16 of 609, across 6 files
  • Use smallest appropriate data typesin 16 of 609, across 6 files

Said here and by no other author read

  • Identify database engine and context first
  • Capture requirements before generating DDL
  • Propose the model before writing DDL
  • Explain design tradeoffs and operational risks
  • Model business language before UI concepts
  • Prefer relational constraints for data integrity

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.