What this prompt does
This prompt creates a migration testing framework for a [framework] application on [database], focused on the [migrations] you list. It validates that up migrations produce the expected schema, that down migrations fully reverse them, and that no data is lost in either direction — the checks that keep a bad migration from reaching production. It also confirms that seeders still run and that foreign-key constraints hold after the change.
It works because a migration failure on a live database is one of the scariest failure modes, so it tests timing and locking before anything touches prod. It simulates each migration on a table with [row_count] rows to measure execution time, analyses which migrations acquire exclusive locks and estimates downtime, and proposes zero-downtime patterns for your [dangerous_migrations]. It also verifies index effectiveness with EXPLAIN on key queries and adds a CI stage that runs against a clone of the production schema, so problems surface in the pipeline rather than on deploy night.
When to use it
- You're about to run a risky migration on a live
[database]and want it tested first - You need to confirm down migrations actually reverse the up migrations
- Large tables mean you must measure timing and locks before production
- Specific
[dangerous_migrations](column rename, NOT NULL backfill) need zero-downtime patterns - You want to verify seeders and foreign keys still hold after a migration
- You want a CI stage that runs migrations against a clone of the production schema
Example output
You get a testing framework: up-migration schema validation, down-migration reversal checks, data-integrity verification for each of your [migrations], a large-table simulation on [row_count] rows with execution timing, a lock analysis estimating downtime, zero-downtime patterns for [dangerous_migrations], seeder-compatibility checks, foreign-key validation, index-effectiveness checks via EXPLAIN, a CI stage running against a production-schema clone, plus test helpers and a migration safety checklist.
Pro tips
- List your real
[migrations]so the framework tests the actual schema changes you're shipping, not generic examples - Set
[row_count]to mirror your largest affected table; a migration that's instant on test data can lock a million-row table for minutes - Always test the down migration too — a rollback that doesn't fully reverse changes is as dangerous as a broken up migration
- Flag the truly risky ones in
[dangerous_migrations](renames, NOT NULL with backfill) so the AI applies zero-downtime patterns like expand-then-contract - Run the CI stage against a clone of the production schema, since structure, indexes, and data volume differ from a fresh test database
- Check index effectiveness with EXPLAIN after the migration, so a new index actually gets used by the queries it was meant to speed up
- Use the lock analysis to schedule risky migrations for low-traffic windows when downtime can't be fully avoided
