data-migration-safetylisted

# Data Migration Safety Schema changes are among the highest-risk operations a team does. They're slow to roll back, can lock tables for minutes, and migrations applied to prod without testing have ended companies. This skill reviews migrations before they ship and refuses ones that fail the safety checklist. ## Auto-trigger criteria Files: `migrations/*.sql`, `supabase/migrations/*.sql`, `*.surrealql`, `prisma/schema.prisma`, `drizzle/**/*.ts`, `alembic/versions/*.py`, `db/migrate/*.rb`, anything matching `*migration*` in path. Also: any `CREATE TABLE`, `ALTER TABLE`, `DROP`, `CREATE INDEX`, `CREATE POLICY` in a SQL file. ## The safety checklist (every migration) ### 1. Reversibility Every migration has an `up` AND a `down`. Without `down`: - BLOCKER for staging. - Even harder rule for production (regulated financial audits expect reversibility evidence). `down` should leave the database in the state it was BEFORE `up` ran. Test it: ```bash # Apply db migrate up # Snapshot pg_dump > after-up.sql # Reverse db migrate down # Re-apply db migrate up # Compare pg_dump > after-up-2.sql diff after-up.sql after-up-2.sql # should be empty ``` Exceptions where `down` legitimately can't restore: data deletions, column drops with information loss. In those cases, the `down` MUST recreate the column type/constraint, with a comment documenting the data loss. ### 2. Lock duration PostgreSQL takes various locks. Most ALTERs take **ACCESS EXCLUSIVE** which blocks reads AND wri