db-architecture-reviewlisted

Document a project's PostgreSQL schema and rigorously review its logical and physical design in one pass — wrong cardinality, unenforced natural keys, junction tables that allow duplicates, tenant-isolation gaps, enum-ish columns with no CHECK, soft-delete/UNIQUE collisions, polymorphic references, and the places where the next feature will hurt. Use this whenever the user asks to review, audit, document, or sanity-check a database schema, data model, ERD, migrations, or "our tables"; when they ask whether a data model will scale or what an extension would break; or when a PR touches schema.sql / migrations and they want a design opinion, not just a syntax check. Also use it when asked to generate database documentation — the docs and the review come from the same run.
greenstevester/db-architecture-reviewer · ★ 1 · Code & Development · score 77

Install: claude install-skill greenstevester/db-architecture-reviewer

# Database architecture review Two halves, deliberately separated: 1. **Mechanical** — `scripts/db-review.ts` parses the DDL with the real PostgreSQL parser, builds a model, joins it with human intent from `narratives.json`, runs ~20 deterministic checks, and writes browsable docs + `schema.json` + `FINDINGS.md`. It exits non-zero on errors, so it can gate CI. 2. **Judgment** — you read `schema.json` and the findings, compare what the narratives *claim* against what the schema *allows*, and reason about extension scenarios the script cannot see. Output: `REVIEW.md`. The split matters. Anything the script can decide, the script decides, every run, for free. Your job is the part that needs the domain story — and to convert every judgment you make into an assertion in `narratives.json` so it becomes a mechanical check next time (the "ratchet"). ## Workflow ### 1. Get a single DDL file The script wants one PostgreSQL DDL file. Find or produce it: | Source | How | |---|---| | `schema.sql` / `db/schema.sql` | use directly | | Flyway migrations `V*.sql` | `cat $(ls db/migration/V*.sql \| sort -V) > /tmp/schema.sql` — DROP/ALTER of columns are applied in order | | Liquibase | `liquibase updateSQL > /tmp/schema.sql` | | Prisma / Drizzle / Django / SQLAlchemy | generate the SQL with the ORM's own tool (`prisma migrate diff --to-schema-datamodel --script`, `drizzle-kit generate`, `manage.py sqlmigrate`) | | Live database | `pg_dump --schema-only --no-owner --no-