Database migration review for lock risk, reversibility and deploy safety

A migration that runs in two seconds on a laptop can lock a production table for minutes. This skill makes Claude Code review migrations the way an experienced database reviewer would, before they are merged.

**What it checks** - **Locking and rewrites**: column type changes, adding a column with a volatile default, adding `NOT NULL` to an existing column, adding foreign keys or check constraints that validate the whole table, and creating indexes without `CONCURRENTLY` on Postgres. - **Transaction rules**: `CREATE INDEX CONCURRENTLY` cannot run inside a transaction, so the migration must opt out of the framework's wrapping transaction (for example `disable_ddl_transaction!` in Rails or `atomic = False` in Django). - **Deploy compatibility**: renames and drops that break the currently running application version. It recommends expand and contract: add new, dual-write, backfill, switch reads, drop old in a later release. - **Data changes**: large `UPDATE` or backfills inside schema migrations, which should be batched and usually run separately. - **Reversibility**: missing or lossy `down` migrations, and whether a rollback would lose data. - **Generated migrations**: autogenerated diffs (Prisma, Alembic, Django) that drop and recreate instead of renaming.

**Output** For each migration: risk level, the specific statement, why it is risky at scale, and a safer sequence of statements or migrations. It asks for the approximate row count of affected tables when the risk depends on size.

**What it will not do** It does not run migrations against any database, and it does not claim exact lock durations. Behavior differs between database versions; when a recommendation depends on version (for example, Postgres 11+ adding a column with a constant default without a rewrite), it states the version assumption.