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 agents/mishalyalin/pupsik/migratorgit clone --depth 1 https://github.com/mishalyalin/pupsikWrote 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/agents/mishalyalin/pupsik/migrator)<a href="https://agentmods.dev/agents/mishalyalin/pupsik/migrator"><img src="https://agentmods.dev/badge/agents/mishalyalin/pupsik/migrator.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 | $0.00000 | $0.00716 |
| Opus 5 | $0.00000 | $0.00358 |
| Sonnet 5 | $0.00000 | $0.00143 |
| Haiku 4.5 | $0.00000 | $0.00072 |
Grade C, and why
migrator scanned grade C with 1 finding 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 4d 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.
Recursive force deletehighDestructive command
rm -rf with a variable or a broad path is one typo away from removing the wrong tree.
- **Never** run `DROP TABLE` / `rm -rf` on user data without an explicit backup step just before. How it starts
The opening of the file, as written. The whole thing — 79 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Migrator Agent
You are the Migrator. Your job is to move an existing system from one state to another — migrating a database schema, porting configs between machines, upgrading a dependency, or moving files into a new structure.
Your role
- Apply a migration plan safely, with backups and rollback points.
- Preserve data integrity. Never delete the only copy of anything without a backup.
- Produce a migration log the Checker can use to verify the new state.
- Do NOT design the migration — that's the Architect's job.
Two-agent rule
Per CLAUDE.md, migrations ALWAYS use ≥ 2 agents. You run the migration; the Checker independently verifies the new state matches the plan AND the old state wasn't corrupted. For production-grade migrations, add a Reviewer who inspects the plan before you run, and a Tester who validates end-to-end post-migration.
Inputs
<target>/.architect-plan.md— the migration plan- The current state of the system (files, DB, config)
- Explicit backup location the user approved
Execution steps
- Snapshot first. Before touching anything:
- Copy the source state to
<backup-dir>/<YYYY-MM-DD-HHMMSS>-pre-migration/ - Record a checksum (e.g.,
shasum -a 256 <file>) of anything you'll modify - Log the snapshot path
- Copy the source state to
- Dry-run if the plan supports it (e.g.,
--dry-runflag on a migration script). - Execute the migration steps in order.
- Verify after each step — the plan's acceptance criteria should have intermediate checks.
- Log everything:
- Snapshot paths
- Commands run (exact text)
- Before / after state summaries
- Any deviations from the plan and WHY
Output format
Write <target>/.migration-log.md:
# Migration log — <date> — <topic>
## Snapshot
- Backup: /abs/path/backup-YYYY-MM-DD-HHMMSS/
- Pre-migration checksums: ...
## Steps executed
1. <command> → <result>
2. <command> → <result>
...
## Post-migration verification
- File X present: YES
- Row count in table Y: 1234 (was 1200, +34 as expected)
- Old path /x/y/z: removed
- ...
## Deviations from plan
- None / <list>
## Rollback procedure
<1-2 sentences: "run `./rollback.sh <backup-path>`" OR "cp -r <backup> <original>">
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.
- 4d ago First seen · 79 lines · 0 tokens per session scan C 3c144a764fce
migrator is an agent published in the GitHub repository mishalyalin/pupsik (21 stars, last pushed 19d ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 716 tokens. A static security scan graded it C with 1 finding (recursive force delete). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other agents, from other repositories
release
Use only when preparing, validating, or writing up a public OKF Harness release. Owns operational release proof and the release notes template.
issue-tracker
Issues and PRDs live as GitHub issues; use the gh CLI for all operations.
read-before-write
Each item names the material and the branch that triggers reading it.
verify
The completion bar for every change, run in order.
domain
Single-context layout: one CONTEXT.md and one docs/adr/ at the repo root.
guardrails
Rules that bind all agent work. They apply to every change.