run-migration
Runs the forward-only Drift/SQLite schema-migration ritual — the most dangerous deterministic operation in an offline-first app: a bad migration silently destroys on-device rows that exist nowhere else. Enforces the exact ordered sequence: take a pre-migration file snapshot before the database is opened, bump schemaVersion by exactly one, write an append-only stepByStep forward step (never edit a shipped step, never write a down migration), commit the drift_dev make-migrations schema snapshot, regenerate, then prove it with tests covering every from→to path (incl. multi-version jumps), a write-at-v(n)/read-at-v(n+1) content test, PRAGMA integrity_check + foreign_key_check, and a forced mid-migration throw that restores the snapshot. Manual, side-effecting workflow. Use when adding or altering a Drift table, column, index, or CHECK; bumping schemaVersion; editing onUpgrade/stepByStep; or writing migration tests.
Install
With your agent
Install OMGSkills skill "zakariaf/flutter-skills:skills/run-migration" into this agent's normal skills directory: call the OMGSkills MCP get_install_plan tool for your agent and run the script it returns (it installs only the pinned commit and verifies SKILL.md), and stop if MCP or the pin is unavailable. Do not overwrite or change existing skills without asking me.
Manual command
git clone https://github.com/zakariaf/Flutter-Skills /tmp/Flutter-Skills && ln -s /tmp/Flutter-Skills/skills/run-migration ~/.claude/skills/run-migrationFrom README
Run migration (forward-only Drift schema migration) Apply a schema change to a local Drift/SQLite database by following the exact ordered ritual below. In an offline-first app there is no server and no re-sync path, so the on-device DB is the single source of truth: a migration that drops or corrupts a column permanently destroys hand-entered records that exist nowhere else, and with no telemetry nobody ever reports it — the user just uninstalls. This is a manual, low-freedom, human-run workflow. Execute the steps in order; do not improvise, reorder, or skip. Non-negotiable rules Take the pre-migration snapshot FIRST — before the database is opened. Do it at the composition boundary that opens AppDatabase, never inside onUpgrade: PRAGMA walcheckpoint(TRUNCATE) any live handle so the -wal is folded into the main file, then copy the DB file and its -wal/-shm sidecars while nothing holds the file open. Opening the database is what triggers the migration.
More from this repo
accessibility-as-code
Enforces accessibility as a correctness property authored into each widget — Semantics(button/label) or...
adaptive-layout
Enforces adapting layout by available CONSTRAINTS/size, never device or platform checks — LayoutBuilder +...
ads-and-iap-monetization
Enforces opt-in, rewarded-first monetization over the service seam — a rewarded view grants exactly one benefit and...