From the first read-only audit to a compiling CMS 13 codebase, showing exactly where ESAI MCP operates, where it stops, and what your team owns at each transition.
cms-upgrade-audit cms-upgrade-execute cms-upgrade-report
Support, any phase: cms-upgrade-status cms-upgrade-help
Audit — read-only codebase scan.
Execute — the compilable CMS 13 codebase.
Post-upgrade analysis — the gap report.
Validate, resolve gaps, and deliver.
Point cms-upgrade-audit at the repository. It reads the CMS 12→13 profiles, auto-detects additional migration paths (Find→Graph, Opti ID, and Commerce when present), and produces a structured markdown audit. Findings are classified by severity, and anything that can't be settled from static analysis is flagged Requires Human Input (RHI). Nothing in the codebase changes.
The audit flags anything a static scan can't settle. Before execution begins, decide per item: is it in scope, deferred, or escalated? Your Optimizely account team can help turn the audit into a scoped, estimated proposal if you need one.
cms-upgrade-execute uses the audit as its execution plan and works phase by phase on a feature branch: fatal blockers first, then package and framework updates, API migrations, and behavioral corrections — logging every change. This is the one skill that rewrites code; the primary deliverable is the upgraded, compilable CMS 13 (.NET 10) codebase.
Lanes run strictly in sequence, never in parallel: CMS 12→13, then Graph, then Opti ID, then Commerce 14→15 (only when Commerce is detected). Check progress anytime with cms-upgrade-status — it also fires automatically at every safe-stop point, so status stays current without anyone asking.
cms-upgrade-report compares the original audit against the change log to identify what was fully resolved, partially addressed, deferred, or surfaced as unexpected complexity — the authoritative task list for Phase 3.
ESAI MCP's part is complete here — but the upgrade is not. Compilable is not the same as correct. It handles structural and mechanical migration reliably; it cannot reason about runtime behavior, domain intent, or business logic. The gap report from Step 3 is the task list for Phase 3.
Regenerates a fresh, self-contained HTML progress dashboard on demand, inferring phase/step position from the Execute change log. Fires automatically at cms-upgrade-execute's own safe-stop points, so status stays current without anyone asking.
The “I’m stuck” entry point for any phase. Triages against real, recurring pitfalls and hands off to cms-upgrade-status directly when there's an active Execute run to look at. Works on any model — no model is rated or gated — and is always available, even before a run is started.
Anything flagged RHI or explicitly deferred was left untouched. Each needs a decision and implementation.
Custom queries, complex conditionals, and domain behavior were migrated in shape, not intent — validate they behave correctly on CMS 13.
Pattern-based migration can break subtle dependencies. Full regression testing is mandatory, not optional.
Migrated Graph queries may compile yet return different results. QA verifies output and relevance, not just compilation.