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 yuri-semenenko/ai-engineering-workspace --skill migration-plangit clone --depth 1 https://github.com/yuri-semenenko/ai-engineering-workspaceWrote 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/yuri-semenenko/ai-engineering-workspace/migration-plan)<a href="https://agentmods.dev/skills/yuri-semenenko/ai-engineering-workspace/migration-plan"><img src="https://agentmods.dev/badge/skills/yuri-semenenko/ai-engineering-workspace/migration-plan.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.1 | $0.00186 | $0.00892 |
| Opus 5 | $0.00093 | $0.00446 |
| Sonnet 5 | $0.00037 | $0.00178 |
| Haiku 4.5 | $0.00019 | $0.00089 |
Grade A, and why
migration-plan 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 7d 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 — 35 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Migration Plan
Sequence a migration so the system stays releasable and reversible at every step, and user-visible behavior does not change. A migration is not a redesign: behavior-preserving by default, new features kept out of it. Prefer many small reversible steps over one big cutover.
The loop
- Pin the invariant. State the user-visible behavior that must not change while the migration runs. This is the safety contract; every step serves it. Capture it as characterization tests or golden output before touching anything.
- Map current to target, and name the seam. Where you are, where you are going, and the boundary you will migrate across (see /module-design). If there is no clean seam yet, creating one is the first slice.
- Choose the migration shape and justify it. Strangler (route work old to new incrementally), adapter / compatibility layer (new behind the interface the old callers already use), expand-contract (add the new, migrate readers, then remove the old), or branch-by-abstraction. Pick per blast radius; say why.
- Slice it. Vertical, independently shippable steps. Each is small, leaves the system releasable, and sits behind a flag if it is user-facing. No big-bang cutover; if one is unavoidable, say why and how you rehearse it.
- Gate each slice with before/after verification. Each slice proves the invariant holds against the characterization captured in step 1. A slice that cannot be verified is not ready.
- Plan rollout and rollback. Feature flag with a removal trigger and date, staged or canary rollout, and explicit rollback criteria per slice (the signal that reverts it). Removing the flag and the dead old path is the final slice, not an afterthought.
- Sequence by dependency and risk. Order the slices, and call out the single highest-risk or least-reversible step with how you de-risk it.
Rules
- Behavior-preserving by default. Keep new behavior or features as a separate change, after the migration.
- Every slice independently shippable and reversible. No step that can only be undone by a second migration.
- Feature flags are temporary: name the removal trigger and date when you add one, and mark it with the
TRADEOFF(...)convention so /debt-ledger tracks the cleanup. - Consumes an RFC decision; do not re-litigate whether to migrate here.
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.
- 7d ago First seen · 35 lines · 186 tokens per session scan A e8248a741237
migration-plan is a skill published in the GitHub repository yuri-semenenko/ai-engineering-workspace (1 stars, last pushed 7d ago), licensed MIT. It adds 186 tokens to every session and 892 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
rework-rate
Measure and interpret PR rework rate — the emerging 5th DORA metric.
My Skill
Content here.
task-generation
Reference material with the canonical task-format grammar and decomposition rules for plan-to-tasks expansion. Loaded on demand by generate-tasks; not directly invokable.
implementation-standards
Reference material with coding standards (defensive coding, error handling, testing patterns). Loaded on demand by the Developer sub-agent (.github/agents/developer.md); not directly invokable.
spec-authoring
Reference material for writing product, technical, and operational specifications (work-item priorities, requirement families, success criteria). Loaded on demand by specify-feature; not directly invokable.
audit
Audits recent work against its Definition of Done and project patterns. Runs the test suite, compares code against the spec, and reports PASS / PARTIAL / FAIL. Also runs the Critical Gate — a safety scan of the diff for destructive or dangerous operations. Generates an incremental prompt pack for any gaps found. With…