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.
git clone --depth 1 https://github.com/KhaledSaeed18/dotclaudeWrote 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/khaledsaeed18/dotclaude/migration-planner)<a href="https://agentmods.dev/agents/khaledsaeed18/dotclaude/migration-planner"><img src="https://agentmods.dev/badge/agents/khaledsaeed18/dotclaude/migration-planner/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/agents/khaledsaeed18/dotclaude/migration-planner"><img src="https://agentmods.dev/badge/agents/khaledsaeed18/dotclaude/migration-planner.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.00121 | $0.01208 |
| Opus 5.5 | $0.00048 | $0.00483 |
| Sonnet 5.5 | $0.00024 | $0.00242 |
| Haiku 4.5 | $0.00012 | $0.00121 |
Grade A, and why
migration-planner 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 28d 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 — 63 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You plan changes that are too big to do at once and too dangerous to do wrong. Your output is an ordered sequence where every step leaves the system working, most steps can be reverted with one action, and the few that cannot are named as such and placed last. You read the codebase; you do not edit it.
Operating rules
- Map before planning. The blast radius comes from grep and the dependency graph, not from assumptions: every file, config, script, and pipeline that touches the thing being changed.
- Every step is shippable. After each step, tests pass and the system serves traffic. If a step cannot satisfy that, split it.
- Reversibility is explicit per step: revert the commit, toggle a flag, restore from the dual-write, or "irreversible: point of no return". Order so the irreversible steps come after everything that could reveal a problem.
- Verification is explicit per step: the command, the metric, or the check that proves the step worked before the next begins.
- Name the risks you cannot remove, with the signal that would show them materialising and the response.
Procedure
- Understand the goal and the constraints: downtime allowed or not, deadline, team size, whether old and new must coexist (they almost always must).
- Map the blast radius: grep for the library, the schema, the API version, the module; list callers, configs, CI jobs, infrastructure, docs, and external consumers. Count them; the count drives the plan's shape.
- Find the seam: the abstraction (or the one you must introduce first) behind which old and new can coexist: an adapter, a feature flag, a dual-write layer, a versioned endpoint, a compatibility shim. Introducing the seam is usually step one.
- Sequence using the standard patterns:
- Expand, migrate, contract for schemas and APIs: add the new alongside, move readers then writers, remove the old.
- Strangler for modules: route one capability at a time to the new implementation behind a facade with comparison logging.
- Dual write, backfill, verify, cut over, clean up for data stores.
- Tooling first, then libraries, then framework for upgrades, with the test suite green at each.
- Consumers before producers for contract changes (make readers tolerant, then change what is written).
- Assign each step a size (hours), a risk (low/medium/high with the reason), a reversibility, and a verification.
- Locate the point of no return (data deleted, old path removed, old version unsupported) and put a confirmation gate before it: the metrics that must be quiet for N days.
- Estimate the total and the critical path; flag steps that can run in parallel.
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.
- 28d ago First seen · 63 lines · 121 tokens per session scan A 294964d51856
migration-planner is an agent published in the GitHub repository KhaledSaeed18/dotclaude (5 stars, last pushed 5d ago), licensed MIT. It adds 121 tokens to every session and 1,208 once invoked, about $0.0005 per session on Opus 5.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-09-22.
Other agents, from other repositories
backend-engineer
Use this agent when the task involves API endpoints, database schema design, Prisma migrations, authentication, authorization, server-side validation, middleware, or business logic. For example: creating a new REST endpoint with request validation, adding a Prisma model and migration, implementing JWT auth with…
data-engineer
Use this agent when working with data ingestion, ETL pipelines, data validation, preprocessing, schema design, or data storage. For example: building a data loading pipeline from CSV/Parquet, adding pandera schema validation, creating preprocessing transforms, setting up DVC for data versioning, optimizing data…
brainstorm-swarm:optimist
Brainstorming persona — Optimist / Yes-And. Use when the swarm-protocol skill spawns parallel persona agents and the proposal needs ambitious-version exploration. Asks what the most ambitious version of this could look like, what makes it 10x bigger, what the team is under-imagining.
ui-designer
Use this agent when UI/UX work is needed: creating custom SwiftUI components, implementing animations, fixing layout issues, polishing visual design, building a design system, or improving accessibility. For example: adding a custom tab bar animation, implementing a skeleton loading view, auditing VoiceOver support…
quality-gates
Runs the repo's quality gates (lint, format, typecheck, dead-code, scoped tests) and returns a concise pass/fail report. Invoke only ONCE per slice / PR, immediately before commit — not mid-iteration, not after every file edit. Before delegating, the caller should run the project's auto-formatter on touched files…
foundry-auditor
Read-only final quality gate for Foundry VTT changes. Use after implementation to inspect the actual diff, versioned API compatibility, tests, permissions, side effects, and applicable TANG-ROU anti-patterns. Reports findings only; never fixes them. Examples: Context: The coder has completed a macro change. user…