← ClaudeAtlas

migration_managementlisted

Author and apply fork-specific DB schema migrations — naming, format, how to apply locally and verify.
jedbjorn/subfloor · ★ 28 · API & Backend · score 78
Install: claude install-skill jedbjorn/subfloor
# migration_management — fork-specific schema changes Migrations live in `.super-coder/migrations/`, apply in numeric order, tracked by the `schema_migrations` ledger table. Engine updates apply pending migrations automatically; apply local pending migrations with `./sc migrate`. **Scope:** fork-specific changes — tables, columns, constraints, or system-content seeds (skills, flavor defaults) this fork needs that will not ship upstream. Upstream engine migrations arrive via `sc update`; no action from you. ## Authoring a migration 1. **Create it through the guardrail:** ```bash ./sc migration new <slug> ``` Use a lowercase `snake_case` slug. The command refuses unexpected duplicate number prefixes, allocates the next free zero-padded number, writes the standard transaction/idempotence skeleton, and (in the subfloor source repo) updates the source removal-test allowlist in the same act. The exact historical `0155` pair is frozen and explicitly allowed; never renumber an applied migration. 2. **Fill in the generated file** at `.super-coder/migrations/NNNN_<slug>.sql`: - Wrap in `BEGIN; ... COMMIT;` - Idempotent: `CREATE TABLE IF NOT EXISTS`, `INSERT OR IGNORE`, `CREATE INDEX IF NOT EXISTS`, `DROP TABLE IF EXISTS` before recreate - Comment header: migration number + intent (+ doctrine notes if relevant) - Structure + system content only — per-instance data (shell memory, grants, roadmap, flags) lives in `.sc-state/local/co