Add db migration
Self-hosted AI coding factory — sandboxed agents deliver tickets to merged code, gated by a human in a dashboard. Local-first, cost-transparent, human-in-the-loop.
npx -y skills add tmj-90/gaffer --skill add-db-migrationAssembled 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.
What its author says it does
Copied from the file, not written here
Use when a ticket requires a database schema change — a new table/column, an index, a constraint, or a backfill. Invoke for "add a migration for X", "alter the schema", or any change to the persisted data model. Schema changes are high-risk; treat them carefully.
SKILL.md
2.8 KB, as published. Nobody here has run it
Add a database migration
Schema changes are high-risk: they can lock tables, drop data, or break running code. Produce a reversible migration that follows the repo's tooling — and escalate when a human decision is needed.
Steps
- Read the lore first. Call
search_lore(Memory MCP) for migration conventions: the tool (Flyway/Liquibase/Alembic/Prisma/Knex/…), naming/numbering, whether migrations must be backward-compatible with running code, and any ADR on zero-downtime changes. - Assess the risk. If the change is destructive (drop column/table, narrow a type,
non-nullable add without default), rewrites a large table, or could cause downtime or
data loss — stop and call
mark_ticket_blockedwith the specifics. A human decides. - Write a reversible migration using the repo's generator. Provide both up and down (or an explicit, justified note when a true rollback is impossible). Prefer additive, backward-compatible steps; split risky changes into expand → migrate → contract phases.
- Make it safe at scale. Add indexes concurrently where the engine supports it; add columns nullable or with a default; backfill in batches, not one statement.
- Apply it against a test/dev database (the context packet's DB; never production) and confirm it runs forward and rolls back cleanly. Add/adjust tests for the new schema.
- Run tests (
run-tests). Evidence the migration file, the apply+rollback output, and test results, then use therecord-evidenceskill and submit for review.
Rules
- Every migration must be reversible, or carry an explicit reason it cannot be.
- Destructive or downtime-risking changes →
mark_ticket_blocked; do not decide alone. - Never run migrations against production; use the test/dev DB from the packet.
- Don't install DB tooling or write secret/
.envfiles — the hook blocks both. - Run on a branch (the
create-branchskill), never a protected branch.
Capture lore
This skill is one of the places durable, reusable knowledge naturally surfaces:
A schema decision or migration constraint future agents must respect — a naming convention, a reversibility rule, or a modelling choice with downstream impact. That kind of fact is lore. Capture it via the lore-capture
protocol in your brief (CLAUDE.factory.md, step 11 "Memory contribution"):
call the Memory MCP suggest_lore once at the close of your work — reusable
conventions, gotchas, decisions, and boundaries only, never per-ticket trivia.