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 Ozzeron/prompt-pack --skill database-migrationsgit clone --depth 1 https://github.com/Ozzeron/prompt-packWrote 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/ozzeron/prompt-pack/database-migrations)<a href="https://agentmods.dev/skills/ozzeron/prompt-pack/database-migrations"><img src="https://agentmods.dev/badge/skills/ozzeron/prompt-pack/database-migrations.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.00097 | $0.02184 |
| Opus 5 | $0.00048 | $0.01092 |
| Sonnet 5 | $0.00019 | $0.00437 |
| Haiku 4.5 | $0.00010 | $0.00218 |
Grade A, and why
database-migrations 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 — 199 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Database Migrations
You evolve a live schema without breaking running code or losing data. Migrations are deployed incrementally; they must be backward-compatible with the currently-running application until the new code is fully rolled out.
When to use
- Adding / removing / renaming columns or tables
- Changing types or constraints
- Adding indexes on production data
- Backfilling or transforming data
- Splitting a column into multiple, or merging columns
Do not invoke for initial schema design (database-schema) or for query problems (database-review).
Scope
In scope:
- Migration mechanics: order of operations, expand/contract pattern
- Naming and numbering conventions
- Lock-aware DDL on Postgres / MySQL / SQL Server
- Rollback strategy
- Splitting schema migrations from data migrations
Out of scope:
- Schema design itself (use
database-schema) - Choosing migration tooling (Prisma, Knex, Alembic, sqlx, golang-migrate, raw SQL) — match what the project uses
Inherits
meta/engineering-principlesmeta/reuse-before-create— before introducing a new migration helper, naming convention, or backfill pattern, check the most recent migrations for an established one and follow it.meta/token-discipline— read the most recent migrations only, not the whole history.
Token discipline (specific)
- Read the most recent 5–10 migration files to learn naming, style, tooling.
- Read the migration runner config (e.g.
prisma/migrations/,alembic.ini,apply-migrations.mjs) once. - Do NOT re-read every historical migration — they're noise for current work.
Golden rules
- No destructive change in the same deploy as the code change. Add the new shape, ship code that handles both, backfill, switch reads, then remove the old shape.
- Every migration is reversible in concept — if the rollback isn't safe (e.g. data loss), say so explicitly in the migration comment.
- Schema migrations and data migrations are separate files. Don't mix DDL and large
UPDATEin the same step. - Long-running migrations don't run inside the deploy step. Use a job runner or a manual operator step.
- Locks matter. A 30-second
ALTER TABLEon a busy table = an outage. Use the non-blocking variants where the DB supports them.
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 Changed · +2 lines · +71 tokens per session 78e5398be958
- 7d ago First seen · 197 lines · 26 tokens per session scan A f8d3060b13e4
database-migrations is a skill published in the GitHub repository Ozzeron/prompt-pack (8 stars, last pushed yesterday), licensed MIT. It adds 97 tokens to every session and 2,184 once invoked, about $0.0005 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
db-context-postgres
Validate that a generic Postgres database (GCP Cloud SQL, GKE Autopilot, self-hosted, etc.) is reachable via psql or pgdump, introspect a user-scoped subset of the schema (extensions, tables, columns, indexes, foreign keys, and optionally RLS policies and functions), and persist the result as DBCONTEXT.md inside the…
db-context-supabase
Validate that a Supabase MCP server is reachable, introspect a user-scoped subset of the database (tables, columns, types, RLS policies, optionally functions and recent migrations), and persist the result as DBCONTEXT.md inside the active task folder; adds a single ## DB context cross-link in SOURCEOFTRUTH.md.…
data-architecture
A data-architecture guide for designing how application data is structured, changed, stored, and used. A schema is the defined shape of stored data, such as tables and fields.
dev-database
A database-development guide focused on safe migrations and schema changes. A migration is a controlled change to the structure of stored data, such as adding a table or changing a column.
db-migration-checker
name: db-migration-checker description: Compares database migration scripts across environments and generates diff reports. version: 1.0.0.
migration-safety-steward
Senior database migration safety steward auditing DDL (ALTER TABLE, CREATE INDEX, DROP COLUMN, ALTER TYPE, ADD CONSTRAINT, trigger changes, FK adds, RENAME COLUMN) for production-unsafe patterns BEFORE the migration is applied. Activates when IMPLEMENTATIONPLAN.md slices include schema changes, when TASKSTATE.md ##…