MPS: Skill for Claude Code

MPS Module and Model Dependencies, Accessory Models

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.

This skill covers the wiring layer of an MPS language — the module descriptor (.mpl) and the per-model imports — and the special role of accessory models and runtime solutions.

Note: accessory wiring does not introduce a new aspect model or stereotype; it edits the existing language descriptor and model imports. When you do need to create a new aspect or stereotyped model, see aspect-model-stereotypes.md for the canonical aspect IDs and @stereotype values.

Critical Directives

• Prefer MCP wiring tools over hand-editing .mpl XML. Hand-editing can silently corrupt the module descriptor. If you must hand-edit (e.g. for accessoryModels, which has no dedicated MCP tool), make a backup, edit only the targeted block, and rebuild the module immediately afterwards so MPS re-reads the descriptor.
• Don't hand-edit languageVersions / dependencyVersions. These are the consumer-side stamps recording which version of another language a module was last migrated against; MPS maintains them. Use the MPS "Update language/dependency versions" action.
• A language's OWN version is a different number, exposed as languageVersion on every Language module in mps_mcp_get_project_structure and derived from the migration scripts by mps_mcp_update_module(operation = "SYNC_VERSION") (max(fromVersion) + 1, computed for you; there is no way to set it to an arbitrary value). It is the integer a migration script's fromVersion gates on, and both MigrationScript and PureMigrationScript get it from their node factory when created through a factory-running path — never set it by hand. Never hand-edit it in the .mpl, and never "fix" a migration by refreshing the consumer stamps instead — that marks the migration as already applied. See module-info-fields.md and the mps-aspect-migrations skill.
• Generator modules have their own dependency list. Add target-language deps to the generator, not the parent language.
• Used languages auto-import when nodes are inserted via mps_mcp_insert_root_node_from_json, mps_mcp_update_node. Manually add a used language only for hand-written code or implicit dependencies.
• A runtime solution holds the stable part of generation (code that doesn't vary with the model). Generate thin code that calls it; don't regenerate it. No MCP tool wires the language's <runtime> block — see references/runtime-solutions.md.