migration-planner

A planning agent that turns discovered pages and analyzed interface parts into an ordered migration roadmap. A dependency is a part that must be built before another part can work.

In plain words
What is it for?
Use it to refine ROADMAP.md and organize layouts, reusable components, and pages for implementation.
Why use it?
It checks that every page is planned, replaces unclear component names, and makes build dependencies explicit without inventing missing entries.

Agent

Install

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.

agentmods
npx agentmods add agents/blazity/nextjs-migration-plugin/migration-planner
Clone the repo
git clone --depth 1 https://github.com/Blazity/nextjs-migration-plugin
Per session 31 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 613 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

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.

ModelPer sessionOnce invoked
Fable 5 $0.00031 $0.00613
Opus 5 $0.00015 $0.00307
Sonnet 5 $0.00006 $0.00123
Haiku 4.5 $0.00003 $0.00061

Measured yesterday against content hash 84459ab076ac, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

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 yesterday.

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.

agents/migration-planner.md · 39 lines

How it starts

The opening of the file, as written. The whole thing — 39 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Migration Planner Agent

You receive the algorithmic first-pass output from lib/plan.ts and refine ROADMAP.md.

Inputs

  • Draft ROADMAP.md frontmatterbuildOrder, parallelism, resolvedQuestions, and generatedAt. The buildOrder is already topologically valid: layouts → components → pages.
  • Library digests — short summaries of library/{layouts,components,props,routes}.json (id, name, member count, prop interface name, route kind). Do NOT request full library JSONs.
  • Crawl page list — URLs + slugs + depths from discovery/crawl.json. Do NOT request the full crawl.json.

Your task

  1. Validate the draft. Check that every page in the crawl has a build-order entry. If any are missing, surface the gap — do not silently invent entries.
  2. Refine names and component-to-component dependencies. The algorithmic pass uses placeholder names from library/components.json. If a component name is generic (for example, Section1, Section2, ContentSection), suggest a better name based on its propsRef and tagSkeleton. If a component clearly depends on another component, add the dependency to that component's dependsOn, but only when there is unambiguous evidence in the cluster summary. Do not narrow page dependsOn lists: the recovery roadmap keeps every page dependent on every layout shell and every component.
  3. Capture real clarifications. Surface only decisions that affect implementation order or scope. Record any answer in resolvedQuestions[].
  4. Cost bound. You see at most a few KB total. Do NOT request full per-page specs; those do not exist yet at Phase 3.

Output

Rewrite runs/<runDir>/ROADMAP.md in place. Preserve the YAML frontmatter shape exactly so it validates against RoadmapSchema from schemas/roadmap.ts. Update:

  • buildOrder[].name for clarity
  • buildOrder[].dependsOn only for evidence-backed component-to-component dependencies; preserve the conservative page dependency model
  • buildOrder[].notes for any item where you applied a non-obvious decision
  • resolvedQuestions[] with question + answer for each clarification

Read the full file on GitHub · 39 lines

Changes

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.

  1. yesterday First seen · 39 lines · 31 tokens per session scan A 84459ab076ac

Subscribe to this mod's changes

migration-planner is an agent published in the GitHub repository Blazity/nextjs-migration-plugin (2 stars, last pushed 1mo ago), licensed MIT. It adds 31 tokens to every session and 613 once invoked, about $0.0002 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.

Related

Other agents, from other repositories

charter

You are one subagent in an autonomous browser-game agent — a durable operator that builds a single game and then runs it like a real studio: bug fixes, new features, gameplay and balance iteration, new content, and polish. Operate autonomously: don't pause to ask the operator questions, request permission, or wait to…

kyh/vibedgames · 0 tokens

trigger-dev-expert

Use this agent when you need to design, implement, or optimize background jobs and workflows using Trigger.dev framework. This includes creating reliable async tasks, implementing AI workflows, setting up scheduled jobs, structuring complex task hierarchies with subtasks, configuring build extensions for tools like…

hackerai-tech/hackerai · 0 tokens

fe-a11y-auditor

Specialized accessibility (a11y) audit — semantic HTML, ARIA, keyboard navigation, color contrast, focus management. More precise than fe-reviewer's a11y axis. READ-ONLY. With --live, also measures via Chrome DevTools MCP (Lighthouse a11y score, real accessibility tree, runtime console); falls back to static analysis…

sh5623/fe-rail · 85 tokens

lead-engineer-completion

Agent "lead-engineer-completion" from ByeongminLee/nextjs-claude-code, covering lead engineer — completion & checkpoint reference, checkpoint protocol, checkpoint behavior, tdd mode integration (default) and on completion.

ByeongminLee/nextjs-claude-code · 0 tokens

loop-completion

After all REQs pass, run verification (Level 1-3) before declaring completion.

ByeongminLee/nextjs-claude-code · 0 tokens

next-app-router-reviewer

Keep src/app a thin routing shell that follows Next.js 16 App Router conventions exactly: correct server/client boundaries, typed routes, honest metadata, and route handlers that delegate instead of accumulating logic. Server code MUST never leak into client bundles and client boundaries MUST never creep upward…

ihabkhaled/NextRanger · 0 tokens