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 adtn0810/truestack --skill truestack-database-migrationsgit clone --depth 1 https://github.com/adtn0810/truestackWrote 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/adtn0810/truestack/truestack-database-migrations)<a href="https://agentmods.dev/skills/adtn0810/truestack/truestack-database-migrations"><img src="https://agentmods.dev/badge/skills/adtn0810/truestack/truestack-database-migrations/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/adtn0810/truestack/truestack-database-migrations"><img src="https://agentmods.dev/badge/skills/adtn0810/truestack/truestack-database-migrations.svg" alt="Reviewed on agentmods" width="80" 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.00183 | $0.02127 |
| Opus 5 | $0.00092 | $0.01064 |
| Sonnet 5 | $0.00037 | $0.00425 |
| Haiku 4.5 | $0.00018 | $0.00213 |
Grade A, and why
truestack-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 10d 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 — 127 lines — stays where its author put it; the contents beside it link to each section on GitHub.
truestack-database-migrations
Changing a live schema is the highest-risk routine work on a self-hosted single server: there is no replica to fail over to, and one stuck lock can freeze the whole app. The job is to evolve the schema without an outage and without losing data — accuracy and stability over cleverness, every breaking change split across deploys.
First, read project memory — CLAUDE.md is auto-loaded (Principles + Boundaries); consult
.ai/memory/ for the DB engine, migration tool, and recorded commands. If none exists, run
truestack-project-memory. This is ask-first, high-risk work: route the plan through
truestack-architecture-planning's approval gate before writing any migration. Then verify the
PreToolUse gate before relying on it — check it is registered in the active hooks config. If
wired, it hard-stops DROP/TRUNCATE/destructive DDL for a human yes before the command
runs, even if settings would allow it; if not wired, obtain that explicit human yes yourself
before any destructive statement. (Details: hooks/README.md at the truestack repo root, when
that repo is present — a standalone copy of this skill won't have it.)
Where this skill sits: it owns the migration artifact — reversible up/down DDL, the backfill,
the expand/contract sequencing. The data-access code that uses the new schema is
truestack-backend-development; sequencing the migrate step in the deploy pipeline is truestack-ci-and-delivery.
1. Never break in one deploy — expand then contract
A zero-downtime breaking change is physically impossible in a single release. Old and new app code run side by side during a deploy, so the schema must stay compatible with both at once. Split it:
- Expand (deploy 1) — add the new column/table, dual-write old+new, backfill, leave the old schema intact. Nothing breaks: both code versions still work.
- Contract (a later deploy, after the new code has soaked) — flip reads to the new path, stop writing the old, then drop. Sequence the irreversible drop as its own final deploy.
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 10d ago First seen · 127 lines · 183 tokens per session scan A 03bbf3e832af
truestack-database-migrations is a skill published in the GitHub repository adtn0810/truestack (2 stars, last pushed 2mo ago), licensed MIT. It adds 183 tokens to every session and 2,127 once invoked, about $0.0009 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
chroma
Embedding database for RAG and semantic search.
pinecone
Managed vector DB for production RAG and search.
postgresql-table-design
Use this skill when designing or reviewing a PostgreSQL-specific schema. Covers best-practices, data types, indexing, constraints, performance patterns, and advanced features.
event-store-design
Design and implement event stores for event-sourced systems. Use when building event sourcing infrastructure, choosing event store technologies, or implementing event persistence patterns.
cqrs-implementation
Implement Command Query Responsibility Segregation for scalable architectures. Use when separating read and write models, optimizing query performance, or building event-sourced systems.
projection-patterns
Build read models and projections from event streams. Use when implementing CQRS read sides, building materialized views, or optimizing query performance in event-sourced systems.