craft-dblisted

# DB Craft This skill encodes one engineer's standard for database work, applied the same way across every repo. The **method and opinions** live here; the **specifics** (which ORM, which dialect, which migration tool, what the tenant-scope helper is called) live in the target repo — always discover them first, never assume or hardcode. ## Operating principle — discover before you build Different repos are at different points in their DB evolution. Before touching anything, spend a few minutes mapping what already exists so you extend rather than duplicate or fight the grain: - `package.json` / lockfile → is `drizzle-orm`, `prisma`, `knex`, `pg`, `mysql2`, or similar already present? - Existing migration directory (e.g. `drizzle/`, `prisma/migrations/`, `db/migrations/`) → what conventions are already established (naming, timestamps, reversibility)? - Schema files → column naming style (camelCase vs snake_case), timestamp columns (`createdAt` / `created_at`), soft-delete column name and type, how tenant id is stored and named. - Query helpers → is there a shared conditions/helpers file that enforces tenant scoping and soft-delete filters? Read it before writing any query. - Dialect → Postgres, MySQL, SQLite? Some patterns (advisory locks, `RETURNING`, expression indexes) are dialect-specific. State what you found, then propose the smallest set of changes that achieves the goal. ## The data layers (work in this order) 1. **Schema design** — model the domain co