What problem does it solve?
When Nx removes, renames, or deprecates an option, executor, or dependency, existing workspaces can break on nx migrate unless a proper migration ships with the change. This Skill guides the authoring of correct first-party Nx migrations so upgrades do not silently break user workspaces.
Core Features & Use Cases
- Migration classification: Decomposes a breaking change into treatments (plain bump, source transform, prompt-only, hybrid, ported upstream migration) and decides whether an entry is needed at all.
- Correct wiring: Covers migrations.json entry shape, version gating,
requires semantics, packageJsonUpdates groups, and the colocated update-VER/NAME.{ts,spec.ts,md} file layout.
- Runtime contract guidance: Companion references explain how
nx migrate actually consumes each key, plus a registry of deprecated patterns to never copy.
- Use Case: You bump a plugin to support a new upstream major (e.g., Vite 6) and need to decide which workspaces get a packageJsonUpdates group, which need a codemod generator, and which need an AI prompt runbook.
Quick Start
Ask the assistant to author an Nx migration for a breaking change, specifying the affected package and the target release train.