MPS: Skill for Claude Code

MPS Behavior Aspect

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 behavior aspect attaches methods and a constructor to a concept, much like adding methods to a Java class. Bodies are written in BaseLanguage + smodel and are callable from any other aspect (editor, constraints, typesystem, generator, intentions, plugin) via node.methodName(...). Lives in <lang>/languageModels/behavior.mps, language jetbrains.mps.lang.behavior.

Critical Directives

• One ConceptBehavior root per concept. The constructor child is mandatory (an empty body is fine).
• Constructors run before the node is attached to the model. parent, ancestors, and all children/descendants evaluate to null. Constructors can only set own property/reference defaults and add mandatory children — use a NodeFactory (actions aspect) for anything that needs the parent/model context.
• Quotations (<C()>) bypass behavior constructors. Use new node<C>() or add new initialized C when you need the constructor to fire.
• Constructors are not inherited — each concept has at most one, and they do not chain (no super()). MPS runs each ancestor's constructor in ancestor-first order independently.
• An overriding method must match the signature of the supertype/interface method exactly. When implementing an interface method (e.g. ScopeProvider.getScope), set overriddenMethod on the new method to the interface declaration — MPS uses it for dispatch and signature validation.
• Behavior calls on a null node do not NPE — MPS returns null for reference/String returns and the default for primitives. Still handle the null return for reference types.
• Hoist shared methods to an abstract super-concept rather than duplicating per-sub-concept ConceptBehavior roots — virtual dispatch covers all non-abstract sub-concepts. (See references/inheritance-and-dispatch.md.)
• Methods are non-virtual by default: all modifier booleans (isVirtual, isAbstract, isStatic, isFinal) default to false. Only virtual methods can be overridden; mark a method virtual up front if sub-concepts may ever need to specialise it.
• When the same piece of node-handling logic repeats across several places or several aspects of one concept (editor, constraints, typesystem, generator, intentions, textgen), extract it into a behavior method and call it everywhere via node.m(...) — this de-duplication is the behavior aspect's primary purpose. Pick the modifier with the table below.
• Edit behavior models through MPS MCP tools (mps_mcp_insert_root_node_from_json, mps_mcp_update_node, mps_mcp_parse_java_and_insert). Do not hand-edit .mps files.
• For MPS-typed return types (sequence<node<X>>, list<node<X>>), mps_mcp_parse_java_and_insert produces Java List<SNode> — replace returnType afterwards with the correct MPS blueprint (see references/variable-declarations.md in the mps-model-manipulation skill root after loading that companion skill from the same origin).
• After edits run mps_mcp_check_root_node_problems and rebuild the language.