From rails-agent-skills
Reviews Rails production database migrations for safety: columns, indexes, backfills, renames, concurrent ops, phased rollouts, locks, rollback, strong_migrations compliance.
npx claudepluginhub igmarin/rails-agent-skills --plugin rails-agent-skillsThis skill uses the workspace's default tool permissions.
Use this skill when schema changes must be safe in real environments.
Generates zero-downtime database migrations with forward SQL, rollback SQL, and deployment sequences. Detects Prisma, Drizzle, Alembic stacks for safe schema changes like add/drop columns.
Manages database migrations and schema changes for Prisma, Drizzle, Django, Rails, Alembic. Assesses risks like data loss and locks, generates safe up/down scripts, validates, and applies with expand-contract for breaking changes.
Plans safe database schema migrations with zero-downtime strategies, rollback procedures, data validation, and version tracking for PostgreSQL, MySQL, and SQLite.
Share bugs, ideas, or general feedback.
Use this skill when schema changes must be safe in real environments.
Core principle: Prefer phased rollouts over one-shot migrations on large or busy tables.
| Operation | Safe Pattern |
|---|---|
| Add column | Nullable first, backfill later, enforce NOT NULL last |
| Add index (large table) | algorithm: :concurrent (PG) / :inplace (MySQL) |
| Backfill data | Batch job, not inside migration transaction |
| Rename column | Add new, copy data, migrate callers, drop old |
| Add NOT NULL | After backfill confirms all rows have values |
| Add foreign key | After cleaning orphaned records |
| Remove column | Remove code references first, then drop column |
DO NOT combine schema change and data backfill in one migration.
DO NOT add NOT NULL on a column that hasn't been fully backfilled.
DO NOT drop columns before all code references are removed.
NOT NULL last.If the project uses strong_migrations, follow it. If it does not, apply the same safety rules manually.
Risky (avoid):
add_column :orders, :status, :string, default: 'pending', null: false
Order.update_all("status = 'pending'")
Safe pattern:
# Step 1: add nullable column
add_column :orders, :status, :string
# Step 2 (separate deploy): backfill in batches outside migration
# Step 3 (after backfill): add constraint
change_column_null :orders, :status, false
change_column_default :orders, :status, from: nil, to: 'pending'
Index on large tables:
# PostgreSQL: concurrent index (no write lock)
disable_ddl_transaction!
add_index :orders, :processed_at, algorithm: :concurrent
# MySQL: online DDL
add_index :orders, :processed_at, algorithm: :inplace
| Mistake | Reality |
|---|---|
| "Table is small, no need for phased migration" | Tables grow. Build the habit for all migrations. |
| Schema change + backfill in one migration | Long transaction, long lock. Always separate them. |
| Column rename with immediate app cutover | App will crash during deploy. Use add-copy-migrate-drop. |
add_index without algorithm: :concurrent | Exclusive lock on large PostgreSQL tables blocks writes. |
| Adding NOT NULL before backfill completes | Migration fails or locks table waiting for backfill. |
| Removing column before removing code references | App crashes when accessing the missing column. |
List risks first.
For each risk include:
For complex type changes, multi-step unique constraints, foreign key validation deferral, safe column removal, and multi-database migrations see PATTERNS.md.
| Skill | When to chain |
|---|---|
| rails-code-review | When reviewing PRs that include migrations |
| rails-background-jobs | For backfill jobs that run after schema change |
| rails-security-review | When migrations expose or move sensitive data |