Evolve schema safely

Skill contextosai/skills/skills/evolve-schema-safely

A collection of Agent Skills — self-contained folders that teach AI agents to perform specialized tasks. Includes a production-readiness harness-audit skill, a plugin marketplace, a SKILL.md spec, and CI validation.

Install

npx -y skills add contextosai/skills --skill evolve-schema-safely

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

1 stars1 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.

What its author says it does

Copied from the file, not written here

Design, implement, or review compatible and reversible database, event, API payload, configuration, or persisted-data schema evolution. Use for migrations, column or field changes, backfills, constraint changes, data transformations, serialization upgrades, zero-downtime deploys, or rollback planning where old and new code or data may coexist. Require explicit expand-migrate-contract sequencing, data invariants, operational bounds, and recovery evidence.

SKILL.md

2.8 KB, as published. Nobody here has run it

Evolve a Schema Safely

Treat schema evolution as a distributed state transition, not a single DDL or file-format edit.

Protocol

Identify producers, consumers, storage, ownership, volume, update frequency, deployment topology, and the maximum period old/new versions can coexist.
State current and target invariants. Profile real data safely for nulls, duplicates, malformed values, cardinality, skew, and referential gaps; do not infer cleanliness from application types.
Classify compatibility for old reader/new writer, new reader/old writer, rollback, replay, and delayed consumers. Include caches, replicas, queues, exports, analytics, and offline jobs when touched.
Prefer expand → migrate → verify → contract:
- expand with additive, backward-compatible shape;
- deploy tolerant readers and controlled dual/single writers;
- backfill in bounded, resumable, idempotent batches;
- verify convergence and constraint readiness;
- contract only after old versions and lagging data are gone.
Define transaction scope, locking, load limits, throttling, checkpointing, retry semantics, and behavior under partial failure.
Make rollback truthful. Distinguish code rollback, traffic rollback, forward repair, and data reversal. Destructive transformations may not be reversible without a preserved source or compensating artifact.
Rehearse on representative disposable data. Verify repeated execution, interruption/resume, mixed versions, boundary values, and rollback/repair.
Gate each phase with measurable entry/exit criteria and telemetry. Remove compatibility code only after evidence shows it is unused.

Guardrails

Never run a production migration, backfill, destructive statement, or live data repair without explicit authority.
Do not add a non-null/unique/foreign-key constraint before proving existing and concurrent writes satisfy it.
Do not use unbounded updates or assume transactional DDL/rollback semantics.
Avoid dual writes without defined ordering, failure reconciliation, and a source of truth.
Treat event and serialized schemas as durable APIs; historical data and delayed consumers are part of compatibility.

Output

Use references/migration-plan.md. Lead with compatibility strategy and the irreversible point, then phases, gates, recovery, and proof.