Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/vmobifystudio/app-dev-team/database-migrationnpx skills add vmobifystudio/app-dev-team --skill database-migrationgit clone --depth 1 https://github.com/vmobifystudio/app-dev-teamWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/vmobifystudio/app-dev-team/database-migration)<a href="https://agentmods.dev/skills/vmobifystudio/app-dev-team/database-migration"><img src="https://agentmods.dev/badge/skills/vmobifystudio/app-dev-team/database-migration.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00064 | $0.00701 |
| Opus 5 | $0.00032 | $0.00351 |
| Sonnet 5 | $0.00013 | $0.00140 |
| Haiku 4.5 | $0.00006 | $0.00070 |
Grade A, and why
database-migration scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured today.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 53 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Database migration
A migration is the one change that cannot be rolled back by reverting the commit. Code reverts; data that has already moved does not. Treat every migration as one-way until you have proven otherwise.
Where a platform skill exists, use it — axiom-database-migration, axiom-swiftdata-migration, or
the auditor for your store. External and optional; missing → follow this file.
Before you write it
- Enumerate every writer and every reader of the affected data (
defect-hunting§1). The migration that stops one layer short is FC-001, and this is the surface where it costs most. - Name the old and new shape explicitly, including what happens to rows that violate the new constraint today. There are always some.
- Decide expand or contract. Almost always expand first:
- Expand: add the new column nullable, write both, backfill, read new with fallback to old.
- Contract: only after every deployed client and server writes the new shape. On mobile that means after the oldest supported app version is gone, which is months, not the next sprint.
- Say how you roll back. If the answer is "restore a backup", say that explicitly — it is a real answer, and it changes the deploy plan.
Writing it
- Forward-only, versioned, and ordered. Never edit a migration that has run anywhere.
- Idempotent: safe to run twice, because it will be.
- Transactional where the engine allows it, and where it does not (many
ALTER TABLEpaths), say so and make each step independently safe. - Never
DROPin the same release that stops using the column. Two releases, minimum. - Backfill in batches with a bound, not in one statement that locks the table.
- A
NOT NULLcolumn gets a default or a backfill in the same migration — this is the single most common way a migration fails in production and not in dev.
Proving it
- Run it against a copy of real-shaped data with the awkward rows in it — nulls, duplicates, the pre-unicode row, the one from the first version. A migration tested only on a fresh database has been tested on the one case that never occurs.
- Run it twice and confirm the second run is a no-op.
- Run the previous application version against the migrated schema. During any rollout both exist at once, and this is the check that catches it.
- Count rows before and after, and state both. "It seemed to work" is not a result.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- today First seen · 53 lines · 64 tokens per session scan A a6ea84bb9256
database-migration is a skill published in the GitHub repository vmobifystudio/app-dev-team (4 stars, last pushed 24d ago), licensed MIT. It adds 64 tokens to every session and 701 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-03.
Other skills, from other repositories
execute-task
Implement one task (or a cohesion bundle) from a signed-off spec (Ready or Active): recompute the execution freshness gate, write the verifying test first, implement to green, run the project's full CI with adaptive retry, converge via the configured reviewsequence (default /polish --nested), then open a draft PR…
builder
Detect a project's stack and recommend or apply the universal mechanical quality guards from planwright's core catalog (formatter, linters, type-checker, test runner, secret scan, commit hooks, CI gate), plus the growable breadth dimensions. Escalates stake-bearing decisions (auth, data modeling, security posture…
spec-walkthrough
Render a spec bundle (or a chosen slice) into a plain-language, didactic comprehension artifact a human reads and judges for themselves: an unaided cold read before kickoff, re-orientation mid-execution, or onboarding to a finished or abandoned spec. Standalone and strictly read-only: it renders any status, never…
drain
Run the on-demand drain pass over every spec bundle's Gate deferral entries: evaluate structured GATE(when:) conditions, surface date and free-text gates, report malformed ones, inventory each live bundle's [manual] test-spec entries, and surface the observations log's unmined state. Read-only; nothing is…
orchestrate
Advance one planwright spec by one step: pick the next ready unit critical-path-first (or a cohesion bundle), run the freshness gate, record the dispatch under the per-spec lock, and dispatch /execute-task via the backend. A stateless, disposable control tower; a reconcile sweep rebuilds from disk. Never merges, marks…
spec-kickoff
Walk a spec bundle section by section to mutual understanding, producing the signed-off kickoff brief downstream skills execute from. On sign-off: runs the Discovery-Rigor lens pass, flips Draft to Ready, records the sign-off record (anchor last), commits, pushes, opens a draft PR, then on clean completion marks the…