maf-migration-plan-creator
Skill14 starsChanged 3 months agoMITView on GitHub
Generates a complete, ready-to-execute MAF migration plan (migration-plan.md) for any .NET codebase. Used by @maf-auditor (which calls this skill after scanning to produce the plan). Use this skill directly when no migration plan exists yet, or when the existing plan needs to be regenerated after a codebase audit. Provides the canonical template, task ID conventions, and the process for populating each task row from an audit scan.
We split this skill into the rules it gives an agent
1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 20
Before filling the template, you need:
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
migration-plan-creator
This skill produces a src/docs/migration-plan.md that the MAF Migration Agent can execute immediately — no manual editing needed.
When to Use This Skill
- Starting a new MAF migration with no existing plan
- Regenerating a plan after the
maf-auditoragent has completed a codebase scan - Creating a plan for a different codebase (not the reference implementation)
How to Generate a Plan
Step 1 — Gather inputs
Before filling the template, you need:
- Package inventory — current versions from all
.csprojfiles - Source pattern scan results — from
maf-auditorPhase C (what old patterns exist, which files, how many occurrences) - API diff output — from
dotnet-inspect diff(Phase B) - CS0618 pre-check results — from
maf-obsolete-api-registrycross-reference (Phase D) - Fan-out topology — from
maf-fan-out-validatorpre-check (Phase E)
Step 2 — Assign Task IDs
Tasks are numbered by phase. Use this phase → task ID mapping:
| Phase | Tasks | Description |
| 1 | T1.1, T1.2, … | Package version updates |
| 2 | T2.1, T2.2, … | Namespace changes |
| 3 | T3.1, T3.2, … | Instructions/Tools placement |
| 4 | T4.1, T4.2, … | Executor migration |
| 5 | T5.1, T5.2, … | Session migration |
| 6 | T6.1, T6.2, … | Response deserialization |
| 7 | T7.1, T7.2, … | Streaming rename |
| 8 | T8.1, T8.2, … | Event type rename |
| 9 | T9.1, T9.2, … | DevUI/Hosting guard |
| 10 | T10.1, T10.2, … | Verification grep checks |
| 11 | T11.1, T11.2 | Polish and done |
Step 3 — Fill the template
See template.md in this directory. Every task row must have:
- Exact file path (relative to repo root)
- Exact before/after code snippet (copy from source — do not paraphrase)
- Guide section reference from
maf-migration-guideSKILL.md section index % Done:0%Verified: empty
Step 4 — Order tasks by dependency
Tasks MUST be ordered so that:
- Packages are updated before any code changes
- Namespaces are updated before executor migration
- Source generator package is added before executor classes are created
- Fan-out executor handlers are migrated before fan-in edges are added
- DevUI guard is last (it depends on all other tasks completing)
Step 5 — Add verification checks (Phase 10 section)
For every old pattern found in the audit, add a verification grep:
Select-String -Path "src/**/*.cs" -Pattern "ReflectingExecutor" -RecurseEach grep must return 0 matches after all tasks in the corresponding phase are complete.
Task Row Format
| # | Task ID | Description | % Done | Verified | Notes |
|---|---------|-------------|--------|----------|-------|
| 1 | T1.1 | Update Microsoft.Agents.AI to 1.3.0 in ClaimsCore.Workflows.csproj | 0% | | |The Verified column gets ✅ only after dotnet build passes with the change applied.
What Makes a Good Plan vs. a Bad Plan
| Good plan | Bad plan |
Before: agent.GetNewThread() / After: await agent.CreateSessionAsync(ct) | Before: "old session API" / After: "new session API" |
File: src/ClaimsCore.Workflows/Workflows/ClaimsFraudDetectionWorkflow.cs line ~42 | File: "the workflow file" |
| Occurrence count: 3 (lines 42, 87, 134) | Occurrence count: "several" |
| Guide section: 6 | Guide section: "sessions" |
| Risk: High — runtime silent failure if not done before fan-in migration | Risk: not assessed |
Be specific. The migration agent will apply changes mechanically — it needs exact before/after text.
In this repository17 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- .github/copilot-instructions.mdCopilot instructions
- cs0618-hunterSkill
- dotnet-inspectSkill
- maf-anti-pattern-scannerSkill
- maf-doctor-self-evolutionSkill
- maf-fan-out-validatorSkill
- maf-from-semantic-kernelSkill
- maf-issue-reporterSkill
- maf-migration-guideSkill
- maf-migration-retrospectiveSkill
- maf-obsolete-api-registrySkill
- maf-release-watcherSkill
- maf-remediation-playbookSkill
- maf-workflow-smoke-testerSkill
- nuget-diff-analyzerSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.