MPS: Skill for Claude Code

MPS Node Editing

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.

The core workflow for mutating MPS nodes through MCP tools. JSON blueprints describe the node hierarchy you want; the tools resolve concepts, references, and used languages on insert.

Critical Directives

• Always use the fully qualified concept name in the concept field — it is unambiguous and does not require a conceptReference.
• Resolve before editing — call mps_mcp_get_current_editor_root_node (for the user's focus) or mps_mcp_search_root_node_by_name (by name) to lock onto the target. Don't guess refs.
• Prefer surgical edits — mps_mcp_update_node (ADD/CHILD or SET/CHILD) preserves persistent IDs. mps_mcp_update_root_node_from_json rewrites the entire root and is wasteful when only one subtree changed.
• Don't delete-and-reinsert to make a small change — deletion destroys persistent IDs and breaks incoming references.
• Cloning an existing node? Use mps_mcp_alter_nodes COPY_NODE, not a JSON blueprint. It clones the subtree natively — correct concept, properties, refs, nested structure — as the next sibling (multi-child role) or new root, then tweak with mps_mcp_update_node. Reserve JSON blueprints for nodes with no close match to copy from.
• Choosing a replacement or filling a typed slot? Ask mps_mcp_query_nodes GET_EXPECTED_TYPE on the node you are about to replace, then confirm a candidate with mps_mcp_query_types IS_SUBTYPE before inserting. An empty slot has no answer, and the bound can depend on the node already there (byte b = 1, return 'c'); null means no usable upper/comparable bound, not “anything goes.” See mps-mcp-workflow/references/analysis-tools/type-queries.md for details.
• Validate frequently — call mps_mcp_check_root_node_problems immediately after inserting or modifying a complex node. "ok": true from insert does not mean the AST is semantically valid; read warnings and details.uncheckedSubtrees, and open a problem's rules[].statement to see which rule reported it.
• Generate deep blueprints, do not hand-nest them — if you write a blueprint as JSON rather than through mps_mcp_parse_java_and_insert, and it holds a BaseLanguage body or nests more than ~5 node levels, generate it with scripts/blueprint.py and pass the printed temp-file path. A hand-written one ends in a long run of ]} pairs; one pair too few is rejected as INVALID_JSON … unbalanced, or, when it is missing mid-input, puts a later role under the wrong node. Plain Java still goes through the parser first (mps-baselanguage).
• A blueprint is not the whole node — the concept's node factory runs first and may add properties, children, and references your JSON never mentions. Do not re-do its work by hand, and do not assume an inserted node contains exactly what you wrote. See "Node factories" below.