database-patterns — Claude Code skill for schemas and migrations

What database-patterns does

The skill feeds the agent a short rulebook for schemas and migrations. The hard rules are blunt: TEXT columns instead of VARCHAR, UUID primary keys instead of SERIAL or BIGINT, soft deletes through a deleted_at TIMESTAMP column rather than DELETE FROM, and foreign keys validated in application code instead of REFERENCES with ON DELETE CASCADE. Every table carries id, created_at, updated_at and deleted_at.

Templates cover the rest. There is a SQL migration with a table, a trigger and partial indexes for soft deletes, an Exposed table object extending UUIDTable, an entity data class implementing Entity<Instant>, and a repository laid out as an interface plus a Default* implementation. Reads go to db.replica, writes to db.primary, and a convert() method maps ResultRow to the entity. A checklist walks through the seven steps of adding a table, from the migration file to repository tests.

A gotchas section catches the usual mistakes. .value applies to id alone — row[Table.projectId] already returns a UUID, so adding .value elsewhere breaks compilation. If your entity extends SoftDeleteTable, redeclaring createdAt, updatedAt or deletedAt triggers a duplicate column error. Flyway rules are strict too: never fill a gap in a deployed migration sequence, and never rename a migration that has already shipped.