MPS: Skill for Claude Code

MPS Generation Plans

Loading companion skills

Companion names in this skill are lazy dependencies: load only those relevant to the current task. If this skill came from an MCP server, use the host's skill loader to resolve the companion's unique discovered entry URI on the same host-assigned originating server. If the host has no server-backed skill loader, stop and report that limitation; do not silently fall back to a filesystem copy. If this skill came from a filesystem catalog, load the named sibling from that same catalog at <skills-root>/<skill-name>/SKILL.md, even if remote skill loaders are also available. Do not invent a tool name or server endpoint.

A generation plan (Plan) is an ordered script of generation steps: which generators run, in what order, where the transient model is persisted (checkpoints), and where generation branches (forks). Without a plan, MPS orders generators by their mutual priorities. A plan states the order once, in one place, so the languages involved need not know about each other.

Language: jetbrains.mps.lang.generator.plan (id 7ab1a6fa-0a11-4b95-9e48-75f363d6cb00), plus jetbrains.mps.lang.smodel (LanguageId) and jetbrains.mps.lang.modelapi (ModulePointer). Inserting plan nodes adds the languages of the concepts inserted to the model's used languages by itself.

When to use a generation plan

• Generators of independent languages must run in a fixed order.
• Cross-model generation: one model's mapping labels must be visible while another model generates (needs a shared plan and a Checkpoint).
• A model needs a second output from a copy of it (a Fork), optionally only under a condition.
• A test or tool must run only some generators (a GeneratorTest with an explicit plan; see the mps-tests skill).

Critical Directives

• A plan is attached as a model, never as a node. A DevKit's plan and a Solution's Custom Generation facet both hold a model reference. MPS runs the model's first Plan root in root order; other Plan roots there serve only as Fork / IncludePlan targets. Keep one main plan per @genplan model; reordering roots changes the plan.
• Attach with mps_mcp_update_module operation=SET_GENERATION_PLAN, planModel=<model> on a DevKit (every model that uses it) or a Solution (every model of it). Do not hand-write the facet memento or the .devkit file, and do not use console Java for it. CLEAR_GENERATION_PLAN detaches. See references/attaching-plans.md.
• A DevKit carries the plan only if it also exports the plan's solution and the languages the plan names: mps_mcp_module_dependency ADD from the DevKit files a Language target into its exported languages, a Solution into its exported solutions, a DevKit into its extended devkits.
• A facet plan beats every DevKit plan of the solution's models. Only DevKits a model imports directly count; an extended DevKit's plan is not inherited. A model may get at most one main plan; extra DevKits may add PlanContributions only.
• ConceptListSelector is not supported: building a plan with it throws, so every model under the plan fails to generate. Condition forks with ParameterEquals (references/fork-selectors.md).
• An explicit plan runs only what it names. A used language no step covers is NOT_IN_PLAN and stays untransformed; generators the default plan pulls in on its own (e.g. jetbrains.mps.lang.core) do not run. Name the target languages' generators too (e.g. a step for jetbrains.mps.baseLanguage).
• Plans and checkpoints are identified by name. Renaming a plan or a checkpoint renames its persisted checkpoint models; two plans with one name collide.
• A plan edit does not make models dirty. After changing or attaching a plan, make with rebuild=true.
• Plan.steps is 1..n, LanguageEntry.language and GeneratorModulePointer.module are required.
• Do not hand-edit serialized .mps, .devkit or .msd files. Use MPS MCP tools.