MPS: Skill for Claude Code

MPS Dataflow 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 dataflow aspect (jetbrains.mps.lang.dataFlow, l:7fa12e9c-b949-4976-b4fa-19accbc320b4) lets a language describe how control and data flow through nodes of a concept. MPS uses that information for reachability analysis, uninitialised-variable checks, and (via IBuilderMode) richer flow analyses such as nullable tracking.

Mental Model

Each DataFlowBuilderDeclaration answers: given a node of concept X, in what order might execution visit its children, and which variables are read or written?

The builder body is a BL StatementList (inside a BuilderBlock). You use normal BL control flow (if, foreach, local variables) to compute which emit instructions to output at runtime. The node implicit parameter (concept NodeParameter) is always in scope — its type is the concept referenced by conceptDeclaration, giving smodel-typed access to children and references.

The MPS dataflow engine builds a control-flow graph from the emitted instructions, then runs analyses (unreachable code, uninitialised variable reads) on that graph. The engine only traces the paths you declare; if no builder exists for a concept, MPS falls back to delegating all children in declaration order.

Critical Directives

• code for is delegation, not a call. Never use jump for child delegation. Use EmitCodeForStatement to inline a child's own builder at this point.
• ifjump is a two-way branch; by BaseLanguage's convention it jumps when the condition is FALSE. Emit it after code for node.condition, towards the else branch, to model an if; a builder may use it the other way (|| jumps when its left side is true).
• An if's else branch is a BlockStatement wrapping a StatementList. IfStatement.ifFalseStatement rejects a bare StatementList; see references/json-patterns/pattern-4-if-statement.md.
• Labels are node references, not string lookups. EmitLabelStatement.name is display-only; jumps reference the label node via LabelPosition.label. Two labels with the same string are still distinct targets.
• Always null-guard 0..1 children with BL if (node.child != null) before emitting code for node.child.
• write node vs write node.link: use write node (just NodeParameter as the variable expression) when the concept node is the variable being declared. Use write node.link (via SLinkAccess) when the node merely references the variable being written.
• Leaf concepts need no builder. The engine treats unbuilt concepts as no-ops, or for ordinary parents delegates to children in declaration order.
• Do not hand-edit serialized .mps dataflow files. Use MPS MCP node tools.