# Migration Reversibility

> Check SQL migration files for irreversible or deploy-breaking operations before running them against production. Use whenever the user writes a migration, mentions ALTER/DROP/migrate, prepares a release containing schema changes, or asks if a deploy is safe — for Supabase, Prisma, Drizzle, or raw SQL alike. Runs fully offline — no API keys, no network, no credentials.

- Skill: `starr-del/migration-reversibility` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add starr-del/migration-reversibility`
- Raw SKILL.md: https://api.skillmd.com/api/skills/starr-del/migration-reversibility/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: Starr-del (https://skillmd.com/u/starr-del)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/starr-del/migration-reversibility

---


# migration-reversibility

Part of **shipsafe** — offline deploy-safety skills. Every script is stdlib-only Python 3.8+; nothing leaves the machine.

```bash
python3 scripts/check_migrations.py <migrations_dir_or_file> [--json]
```

Three finding categories:
- **DATA_LOSS** — DROP TABLE/COLUMN without co-located backup, TRUNCATE, DELETE without WHERE, type narrowing to VARCHAR(n). Rolling back the *deploy* does not roll back these — the data is gone.
- **DEPLOY_BREAKER** — operations that break the *currently running* app version during the deploy window: ADD COLUMN NOT NULL without DEFAULT, RENAMEs (old code queries the old name), CREATE INDEX without CONCURRENTLY (locks writes on Postgres).

- **SECURITY** — Row Level Security audit. Explicit `DISABLE ROW LEVEL SECURITY` is critical anywhere. For Supabase projects (detected via path or auth.uid()/anon-grant signals — non-Supabase databases are deliberately not flagged), tables CREATEd without a matching `ENABLE ROW LEVEL SECURITY` are flagged high: on Supabase the public anon key can query any table in the public schema, so a table without RLS is publicly readable and writable. This is the #1 documented cause of vibe-coded app data breaches; when it fires, walk the user through deny-by-default policies.

The governing rule, which is worth stating to the user verbatim: **a migration is deploy-safe only if the previous version of the app still works after it runs.** That's what makes rollback possible.

For flagged RENAMEs and DROPs, recommend the expand/contract pattern: add the new thing → dual-write → migrate readers → remove the old thing in a later release. SQL comments are stripped before analysis, and a backup statement in the same file downgrades DROP severity.

Exit codes: 0 clean, 1 findings.

All paths below are relative to this skill's directory (migration-reversibility/).