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/hautc-it/cil/migrationnpx skills add hautc-it/cil --skill migrationgit clone --depth 1 https://github.com/hautc-it/cilWhat 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.00050 | $0.01181 |
| Opus 5 | $0.00025 | $0.00590 |
| Sonnet 5 | $0.00010 | $0.00236 |
| Haiku 4.5 | $0.00005 | $0.00118 |
Grade A, and why
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 2d 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 — 94 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Skill: Database Migration
A migration is a deploy event, not a code change. Reason about it that way.
Project Context
Existing project
- Read
CLAUDE.md— migration rules, DB constraints, or deploy-window requirements take priority. - Identify the database and migration tool — read existing migration files to understand the naming convention, file structure, and execution mechanism already in use.
- Check data volume — how many rows are in the affected table? This determines whether the migration is instant or requires a maintenance window and special handling.
- Read existing migration patterns — how does this project handle rollbacks? Are down migrations written? Are backfills done inside the migration or via a separate script?
- Search memory —
memory_search("migration [table] schema")— retrieve prior decisions, known lock patterns, or constraints on this table. - Apply the checklist and patterns below within the project's established approach.
Greenfield project
No schema exists yet — foundational choices here are expensive to undo:
- Choose the migration tool — use the standard one for the platform and ORM in use. Prefer a dedicated migration tool over raw SQL files; it gives you history, ordering, and reproducibility.
- Establish file naming convention — timestamp prefix (
YYYYMMDDHHMMSS_description) is safer than sequential numbers for teams working on parallel branches. - Add audit columns from day one —
created_at,updated_at(anddeleted_atif soft-delete is needed) on every table. Retrofitting these later requires locking every table. - Decide rollback strategy upfront — write down migrations from day one, or explicitly document that the project uses forward-only migrations. Changing this policy later is disruptive.
- Set the backfill standard — batched (small chunks), idempotent (safe to re-run), throttled (leave headroom for live traffic). Write this into
CLAUDE.md. - Store the decision:
memory_store("decision", "migrations: tool=[x], naming=[timestamp], rollback=[x], audit cols=created_at+updated_at", ["migration", "database", "conventions"])
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.
- 2d ago First seen · 94 lines · 50 tokens per session scan A 5531789c799f
migration is a skill published in the GitHub repository hautc-it/cil (1 stars, last pushed 1mo ago), licensed MIT. It adds 50 tokens to every session and 1,181 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-08-31.
Other skills, from other repositories
caching
Caching strategies — invalidation, TTL guidelines, cache keys, cache layers, and when not to cache. Use when implementing or reviewing caching logic.
database-optimizer
Use when investigating slow queries, analyzing execution plans, or optimizing database performance. Invoke for index design, query rewrites, configuration tuning, partitioning strategies, lock contention resolution.
cli-audit-data
Audit PostgreSQL database safety in Rust/SQLx applications. Use for schemas, migrations, constraints, indexes, transactions, repositories, state transitions, idempotency, concurrency, queues, multi-tenancy, soft deletion, ledgers, auditability, repair, database incidents, or whenever SQLx and PostgreSQL changes could…
cli-forge-data
Design and implement safe PostgreSQL database changes for Rust/SQLx applications. Use for new schemas, migrations, constraints, indexes, repositories, transaction boundaries, state machines, idempotency, concurrency control, queues, multi-tenancy, soft deletion, ledgers, outbox/inbox, repair jobs, or corrections…
postgres-pro
Use when optimizing PostgreSQL queries, configuring replication, or implementing advanced database features. Invoke for EXPLAIN analysis, JSONB operations, extension usage, VACUUM tuning, performance monitoring.
sql-pro
Use when optimizing SQL queries, designing database schemas, or tuning database performance. Invoke for complex queries, window functions, CTEs, indexing strategies, query plan analysis.