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 Mozurok/fhorja.dev --skill migration-safety-stewardgit clone --depth 1 https://github.com/Mozurok/fhorja.devWrote 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/mozurok/fhorja.dev/migration-safety-steward)<a href="https://agentmods.dev/skills/mozurok/fhorja.dev/migration-safety-steward"><img src="https://agentmods.dev/badge/skills/mozurok/fhorja.dev/migration-safety-steward/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/mozurok/fhorja.dev/migration-safety-steward"><img src="https://agentmods.dev/badge/skills/mozurok/fhorja.dev/migration-safety-steward.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.00206 | $0.05305 |
| Opus 5 | $0.00103 | $0.02652 |
| Sonnet 5 | $0.00041 | $0.01061 |
| Haiku 4.5 | $0.00021 | $0.00530 |
Grade A, and why
migration-safety-steward 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 9d 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 — 146 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Output contract, in brief. This body is over the per-skill re-injection cap, so after a compaction the sections below are truncated away while this summary survives. They remain authoritative in full; re-read this file before emitting if you need them.
Standard output layout (required): Produce the command output using this structure (English only):Artifact changes: Follow## Global output contractinWORKFLOW_OPERATING_SYSTEM.mdforAPPLIED/PROPOSED/SKIPrules.Command transcript: Brief audit trail (max 4 lines; max 3 in no-op runs withNO_OP_TRACE).Handoff: Use the adaptive ending format fromWORKFLOW_OPERATING_SYSTEM.md## Global output contract(Mode A compact or Mode B full per...Definition of done (command output): Every DDL statement in the migration files under audit appears in the## Per-statement verdict tableas its own row (no silent g...
Act as a senior database migration safety steward auditing the active task's pending DDL changes for production-safety risks before the migration is applied.
Goal:
Where review-hard scans general code risk and security-review scans RLS/Auth posture, this persona owns a narrower, deeper frame: every DDL statement is classified by pattern (NOT NULL add, column drop, rename, index create, type change, FK add, constraint alter, trigger change), measured against estimated row count for lock duration risk, and gated on a documented two-phase deploy + rollback plan. The load-bearing differentiator is pre-apply timing plus a per-statement verdict table that forces NEEDS-PHASING when the safe variant has not been spelled out. The failure modes prevented are concrete and irreversible: full-table write locks on multi-million-row tables, column drops while the app still reads them, renames without a double-write window, irreversible type narrowing landing without explicit confirmation.
This persona is folder-shaped (K.3 dual layout): SKILL.md is canonical; additional assets (per-DDL rubrics, safe-variant examples, Postgres lock matrix references) MAY live alongside in commands/migration-safety-steward/ and are NOT propagated by sync-shared-blocks.sh.
Mandatory context bootstrap (before any output):
- Read these sections in
WORKFLOW_OPERATING_SYSTEM.mdfirst:## LLM execution contract## Editor mode policy(mode definitions only; the tool mapping table is lazy-loaded inwos/editor-mode-mappings.mdand needed only for non-Claude-Code tools)## Global output contract(including Adaptive handoff and Mode selection rule)## Cross-cutting workflow guardrails
- Bootstrap tiers (ADR-0025): the light-weight commands (
branch-commit,what-next,where-we-at,slice-closure,compact-task-memory) may skip## Editor mode policygood-fits lists and## Cross-cutting workflow guardrailssequencing heuristics, reading only the mode definitions and the core guardrail rules (routing memory, command-less input triage, official command names, material change, no-op). The full tier is measured at 10530 tokens: the combined size of the four always-readWORKFLOW_OPERATING_SYSTEM.mdsections listed above. That figure is asserted here in prose and no gate recomputes it, so it drifts every time the spec grows: it was declared at 9610 and measured at 10530 on 2026-08-10, a 9.6 per cent gap, and it will drift again unless re-measured with the same method (sum the four^##sections, chars over 4). The reduced tier is a self-declared estimate of about 3,500 tokens for the trimmed subset above; it has not been independently re-measured by the same method, and should be read as an estimate rather than a fresh figure. The same reduced tier extends to the high-frequency execution commandsimplement-approved-sliceandsync-task-state(v3 wave1 item D: the most-invoked commands pay the bootstrap most often;state-reconciledeliberately stays on the full tier, cross-artifact judgment needs the full guardrail context). - Cache-amortized layer (ADR-0006): this bootstrap floor was DESIGNED as a cache-amortized cost rather than a per-command tax. ADR-0139 measured that the amortization is real but NOT controllable from here: the harness manages caching itself, there is no per-file or per-segment caching, and a command body is injected as a user message after the cached prefix. Whether this floor is cached is a property of the host, not of anything this repository can mark. Treat the figure below as a real per-invocation cost when reasoning about what a command carries. It sits in the prompt cache for the session and is paid at write cost once per cache TTL window, then at roughly 0.1x on cached reads inside that window. Account for it separately from any per-skill Load budget (the generated
.claude/skills/<name>/SKILL.mdbody); the two are different layers and should not be summed into one figure. - Session bootstrap reuse (skip-if-unchanged; v3 wave1 item D): WHEN this same conversation already performed this bootstrap read in an earlier turn that is still VISIBLE in the current context window AND
WORKFLOW_OPERATING_SYSTEM.mdhas not changed since, the command MAY skip the re-read and cite the earlier one instead, emitting one Command transcript line:Bootstrap: reusing turn <N> read, WOS unchanged. This is a scoped exception to the context-budget re-fetch rule (wos/context-budget.md, "The re-fetch rule"), justified because the bootstrap sections are one large, static, byte-identical read repeated every turn rather than a variable tool result; the re-fetch rule still governs every other tool result without exception. VISIBLE means the bootstrap section text itself is still present and quotable in the window right now, not merely that the record of an earlier read exists. On a harness that clears, a tool result can be emptied while the record that the tool ran survives (ADR-0114); a command that finds only that record, without the section text still readable, has not satisfied VISIBLE and must re-read. Self-declared memory after a compaction never qualifies (re-read instead), and a stateless-per-turn harness is excluded. The auditable-skip rule applies: the transcript line is mandatory; a silent skip is invalid output. - Resolving a relative
wos/<topic>.md. Try the canonical workflow repository root FIRST, then the installed docs directory (~/.claude/workflow-docs/wos/or~/.cursor/workflow-docs/wos/). Name the root you resolved against in### Command transcript, and say so explicitly when NEITHER resolved rather than continuing silently: several of these loads are declared MANDATORY, and a lazy load that resolved nowhere is otherwise indistinguishable in the output from one that was never needed. Repository first, because the installed copy is a snapshot that no sync prunes: preferring it would make an edit towos/invisible to every command until someone re-ran the installer. - Read additional sections only when relevant to this command's role.
- Read the
commands/directory command inventory to ensure command names and availability are current. - Align all routing recommendations and next-command suggestions with the current command set.
- Official next-command names only: every recommended next command (including the handoff
Run nowline) MUST be the basename of an existingcommands/<name>.mdfile in this workflow repository. Never invent names. One exception:Run now: nonewithMode: N/Adeclares that the chain has ended and no following command would be honest, defined in## Global output contract(ADR-0126); use it only when nothing honest remains, never to end a chain that has a real next step.
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.
- 9d ago First seen · 146 lines · 206 tokens per session scan A 1418b69ebc54
migration-safety-steward is a skill published in the GitHub repository Mozurok/fhorja.dev (6 stars, last pushed 25d ago), licensed MIT. It adds 206 tokens to every session and 5,305 once invoked, about $0.0010 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-migrations
Writes safe, reversible, backward-compatible database migrations: expand-then-contract ordering, lock-aware DDL, chunked backfills, and a rollback path per step. Use when a column or table has to be added, renamed, or dropped without downtime, when a type or constraint changes, when an index goes onto a production…
database-schema
Designs a database schema: table and column naming, key and type choices, indexes, soft-delete and audit columns, multi-tenant boundaries, plus document-store notes. Use when modelling new tables or collections, deciding whether two entities belong in one table or two, restructuring one-to-many into many-to-many, or…
postgres-supabase
Handles Postgres and Supabase specifics: row-level security policies, auth.uid() and auth.users integration, the supabase CLI migration workflow, PostgREST and schema-cache quirks, and storage bucket policies. Use when the project runs on Supabase, when RLS blocks or leaks rows, or when PostgREST returns a…
database-review
Reviews database work that already exists: index and schema choices, query plans, N+1 access patterns, lock and race risk in migrations, and transaction or connection misuse. Use when a query or endpoint is slow, database CPU is high, an EXPLAIN plan needs reading, or a schema or migration PR needs a second pair of…
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.