agentsclimarketplace
Sign in

Migration safety check

Skill amineorion/claude-code-safety-skills/skills/migration-safety-check

Review a database migration for safety before it runs against a multi-tenant production database, where one bad migration hits every customer at once. Use when the user writes, edits, or is about to run a migration, or asks whether a schema change is safe.From its SKILL.md

Install
npx -y skills add amineorion/claude-code-safety-skills --skill migration-safety-check

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

2.3 KB, 463 tokens by cl100k_base, as published. Nobody here has run it

Migration safety check

A migration in a multi-tenant system runs against every tenant at once. There is no "blast radius of one." Review the migration ($ARGUMENTS if given, otherwise the migration files in the current diff) against the checklist below and report each risk with the specific line and a safer alternative.

Destructive / irreversible

  • Dropping a column or table — is the data backed up or is this truly dead? Is there a down-migration? Prefer a deprecate-then-drop across two releases.
  • DELETE/UPDATE data migrations without a WHERE, or with a WHERE that doesn't bound the rows — this rewrites every tenant's data.
  • Type changes / NOT NULL adds on a populated column — will they fail or lock on real data volumes?

Locking & availability (you can't take all tenants down)

  • Adding an index without CONCURRENTLY (Postgres) locks writes on a large table.
  • ALTER TABLE that rewrites the table holds a lock proportional to row count.
  • Long-running data backfills inside the schema migration — split them out and batch.

Tenant correctness

  • New tables: do they carry a tenant column and the right constraints/RLS policy from the start? A table that ships without tenant scoping is a future leak.
  • Backfills: are they scoped/batched per tenant, or one statement across all rows?
  • Defaults and unique constraints: are uniqueness scopes (tenant_id, ...) rather than global where they should be per-tenant?

Process

  • Is this migration applied by a human/CI on a schedule, never ad hoc by the agent?
  • Has it been run against a copy of production-scale data, not just an empty dev DB?

Output

VERDICT: SAFE TO APPLY | NEEDS CHANGES | DO NOT APPLY
BLOCKERS:
  - <line> — <risk> — <safer approach>
WARNINGS:
  - <line> — <risk> — <mitigation>

State the expected lock/rewrite behavior at production row counts, not just "looks fine."

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Keep looking

Skills are one crate of 326,851. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.