Install
$ agentstack add skill-khaledsaeed18-dotclaude-db-migration-safety ✓ scanned · ✓ verified — works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
About
A migration that is correct on an empty dev database can still take a production table offline. Judge every migration by what it does under load on the largest table it touches: what lock it takes, for how long, and what the old application version does while the new schema is live. When any answer is "depends", assume the worst table and the slowest query.
Step 1: Establish the blast radius
- Read the migration and identify every table it touches, then find out (or ask) roughly how large and how hot each one is. A pattern that is fine on 10k rows is an outage on 100M.
- Identify the engine and version (Postgres, MySQL 8, SQLite, ...) from config; lock behavior differs materially between them, and between versions.
- Identify the deploy model: is the old app version still running while this migration executes (rolling deploy, multiple replicas)? Almost always yes; review under that assumption.
Step 2: Check the dangerous patterns
Flag any of these, with the safe alternative:
Locking and rewrites
- Any statement that rewrites the table or takes an exclusive lock for its duration: changing a column's type, adding a column with a volatile default (pre-Postgres 11),
ALTER TABLEon MySQL withoutALGORITHM=INPLACE/INSTANTsupport. Alternative: add a new column, backfill, swap. CREATE INDEXwithoutCONCURRENTLY(Postgres) on a live table blocks writes for the build.CONCURRENTLYcannot run inside a transaction; the migration tool must support that (most do via a flag ordisable_ddl_transaction!).- Adding a
NOT NULLconstraint or foreign key that validates existing rows scans the table under lock. Alternative: add asNOT VALID/ unvalidated, thenVALIDATE CONSTRAINTseparately.
Deploy-order breaks (expand-contract violations)
- Dropping or renaming a column or table the currently-deployed code still reads or writes. Renames are two deploys minimum: add new + dual-write, migrate readers, then drop the old one in a later release.
- Making a column
NOT NULLwhile the running app still inserts without it. - Enum or check-constraint tightening that existing rows or in-flight writes violate.
Backfills
- Backfilling inside the schema migration itself, in one transaction. A backfill is data movement, not schema: run it separately, in batches (thousands of rows per batch, pausing between), idempotent and resumable, keyed on primary-key ranges rather than OFFSET.
- Backfill and constraint in one step; the constraint comes after the backfill completes and is verified.
Operational
- No down migration, or a down migration that drops data the up migration created (state whether down is actually safe to run, not just present).
- Long statements without a
lock_timeout/statement_timeoutguard (Postgres): a blockedALTERqueues behind a long-running query and then blocks everything behind it. Set a short lock timeout and retry rather than waiting indefinitely. - Mixing schema change and unrelated data change in one migration file; they have different risk profiles and rollback stories.
Step 3: Verify what can be verified
- Run the migration against a local or staging copy and read the SQL the tool actually emits (
--dry-run,sqlmigrate,db:migrate:statusequivalents); ORMs sometimes generate a rewrite where the model diff looked additive. - Confirm the migration is wrapped (or deliberately not wrapped) in a transaction as the engine requires.
- For the reviewed-only case (no database available), say so, and mark which findings are static-analysis-certain versus needing a dry run.
Step 4: Report
Findings ordered by severity: outage risks (locks, rewrites, deploy-order breaks) first, then correctness (rollback, constraint gaps), then hygiene. For each: the statement, what happens on the big table, and the concrete safe sequence, written as actual migration steps in the project's own tool syntax. If the migration is safe as written, say that plainly and note the one or two assumptions the judgment rests on (table size, engine version).
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: KhaledSaeed18
- Source: KhaledSaeed18/dotclaude
- License: MIT
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet — be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.