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 skills add orlando-japan/claude-code-setting --skill migration-planninggit clone --depth 1 https://github.com/orlando-japan/claude-code-settingWrote 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/orlando-japan/claude-code-setting/migration-planning)<a href="https://agentmods.dev/skills/orlando-japan/claude-code-setting/migration-planning"><img src="https://agentmods.dev/badge/skills/orlando-japan/claude-code-setting/migration-planning.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.1 | $0.00037 | $0.00949 |
| Opus 5 | $0.00018 | $0.00475 |
| Sonnet 5 | $0.00007 | $0.00190 |
| Haiku 4.5 | $0.00004 | $0.00095 |
Grade A, and why
migration-planning 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 6d ago.
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 — 89 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Migration planning
A migration is a sequence of reversible steps that gets you from A to B without breaking the world in between. The hard part is not the destination — it's what runs during the transition.
The expand / migrate / contract pattern
This is the core template. It applies to schemas, APIs, config, infra, almost everything.
- Expand. Introduce the new thing alongside the old. Both exist; nothing yet depends on the new.
- Migrate. Gradually shift reads, writes, and callers to the new thing. Dual-write, dual-read if needed. Verify equivalence under load.
- Contract. Once nothing uses the old thing, remove it.
Rollback is possible at any step. Skipping expand or mashing expand + contract = no rollback.
Schema migrations specifically
Safe changes (can ship without coordination)
- Adding a nullable column.
- Adding a new table.
- Adding a non-unique index (CONCURRENTLY if Postgres).
- Widening a column (e.g., VARCHAR(50) → VARCHAR(200)).
- Adding a check constraint marked NOT VALID, then validating later.
Breaking changes (need expand/migrate/contract)
- Renaming a column → add new, dual-write, migrate data, switch reads, drop old.
- Changing a column type → add new column, backfill, switch reads, drop old.
- Dropping a column → stop writes, wait for all deploys, then drop.
- Adding NOT NULL to an existing column → add as nullable, backfill, add NOT NULL constraint as NOT VALID, validate, enforce.
- Adding a unique constraint → add unique index concurrently, then promote.
Dangerous patterns
- ALTER TABLE on large tables without
CONCURRENTLY→ locks, downtime. - DROP COLUMN while old code still reads it → crashes.
- NOT NULL + default for 50M rows in one statement → locks for minutes.
- Renames → the worst. Almost always cheaper to keep the old name.
API migrations
- Add v2 alongside v1. Don't touch v1.
- Dual-call from callers when safe, compare outputs, migrate reads.
- Deprecate with a date. Sunset on day N + 90, not "eventually."
- Remove only after zero traffic for N days (measure, don't guess).
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.
- 6d ago First seen · 89 lines · 37 tokens per session scan A d77bcbb81500
migration-planning is a skill published in the GitHub repository orlando-japan/claude-code-setting (2 stars, last pushed 3mo ago), licensed MIT. It adds 37 tokens to every session and 949 once invoked, about $0.0002 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-08-31.
Other skills, from other repositories
database-migration
Safe patterns for evolving database schemas in production with decision trees and troubleshooting guidance.
Database Migration Testing
Testing database migration scripts for correctness, rollback safety, data integrity, and zero-downtime migration patterns.
sql-reporting
Conventions and review steps for writing analytics SQL against the warehouse. Use whenever the task involves querying tables, building a report, or aggregating metrics.
smart-data-analysis
A central workflow for handling data questions and data assets across tables, views, metrics, SQL, charts, and Business Knowledge Networks.
smart-data-collection
A workflow for extracting structured information from images and documents such as PDFs, Word files, and spreadsheets, then storing it in a database.
ontology-core
A command-line tool for managing and querying Business Knowledge Networks, data sources, data views, and platform monitoring resources.