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 KhaledSaeed18/dotclaude --skill db-migration-safetygit clone --depth 1 https://github.com/KhaledSaeed18/dotclaudeWrote 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/khaledsaeed18/dotclaude/db-migration-safety)<a href="https://agentmods.dev/skills/khaledsaeed18/dotclaude/db-migration-safety"><img src="https://agentmods.dev/badge/skills/khaledsaeed18/dotclaude/db-migration-safety.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.00088 | $0.00973 |
| Opus 5 | $0.00044 | $0.00487 |
| Sonnet 5 | $0.00018 | $0.00195 |
| Haiku 4.5 | $0.00009 | $0.00097 |
Grade A, and why
db-migration-safety 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 7d 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 — 46 lines — stays where its author put it; the contents beside it link to each section on GitHub.
A migration that is correct on an empty dev database can still take a production table offline. Judge every migration by what it does under load on the largest table it touches: what lock it takes, for how long, and what the old application version does while the new schema is live. When any answer is "depends", assume the worst table and the slowest query.
Step 1: Establish the blast radius
- Read the migration and identify every table it touches, then find out (or ask) roughly how large and how hot each one is. A pattern that is fine on 10k rows is an outage on 100M.
- Identify the engine and version (Postgres, MySQL 8, SQLite, ...) from config; lock behavior differs materially between them, and between versions.
- Identify the deploy model: is the old app version still running while this migration executes (rolling deploy, multiple replicas)? Almost always yes; review under that assumption.
Step 2: Check the dangerous patterns
Flag any of these, with the safe alternative:
Locking and rewrites
- Any statement that rewrites the table or takes an exclusive lock for its duration: changing a column's type, adding a column with a volatile default (pre-Postgres 11),
ALTER TABLEon MySQL withoutALGORITHM=INPLACE/INSTANTsupport. Alternative: add a new column, backfill, swap. CREATE INDEXwithoutCONCURRENTLY(Postgres) on a live table blocks writes for the build.CONCURRENTLYcannot run inside a transaction; the migration tool must support that (most do via a flag ordisable_ddl_transaction!).- Adding a
NOT NULLconstraint or foreign key that validates existing rows scans the table under lock. Alternative: add asNOT VALID/ unvalidated, thenVALIDATE CONSTRAINTseparately.
Deploy-order breaks (expand-contract violations)
- Dropping or renaming a column or table the currently-deployed code still reads or writes. Renames are two deploys minimum: add new + dual-write, migrate readers, then drop the old one in a later release.
- Making a column
NOT NULLwhile the running app still inserts without it. - Enum or check-constraint tightening that existing rows or in-flight writes violate.
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.
- 7d ago First seen · 46 lines · 88 tokens per session scan A 5179170011a5
db-migration-safety is a skill published in the GitHub repository KhaledSaeed18/dotclaude (5 stars, last pushed 6d ago), licensed MIT. It adds 88 tokens to every session and 973 once invoked, about $0.0004 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-expert
Advanced database design and administration for PostgreSQL, MongoDB, and Redis. Use when designing schemas, optimizing queries, managing database performance, or implementing data patterns.
generic-fullstack-feature-developer
Guide feature development for full-stack applications with architecture focus. Covers Next.js App Router patterns, NestJS backend services, database models, data workflows, and seamless integration. Use when adding new features, refactoring existing code, or planning major changes.
langgraph-memory-checkpointer-database-adapters
Guidelines and instructions for LangGraph memory checkpointer database adapters.
pinecone-metadata-index-properties
Guidelines and instructions for Pinecone metadata index properties.
pinecone-query-parameters-filters
Guidelines and instructions for Pinecone query parameters filters.
pinecone-vector-db-index-setups
Guidelines and instructions for Pinecone Vector DB index setups.