MPS: Skill for Claude Code

MPS Typesystem and Checking 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 typesystem aspect gives nodes types and reports semantic errors. It combines two related sub-aspects:

• Typesystem rules — compute types and constraints on them (InferenceRule, SubtypingRule, InequationReplacementRule, ComparisonRule, SubstituteTypeRule).
• Non-typesystem checking rules — produce errors/warnings/messages without contributing to type inference (NonTypesystemRule, a.k.a. "checking rule").

Lives in <lang>/languageModels/typesystem.mps, language jetbrains.mps.lang.typesystem. Rule bodies are BaseLanguage + smodel + collections + closures.

Critical Directives

• One InferenceRule (or other root rule) per concept whose type/check you compute. Multiple rules collectively constrain a node — keep each rule focused.
• The infer prefix makes an inequation soft (the solver tries to satisfy it, will not immediately error). Without infer, violating the inequation reports an error. Choose deliberately.
• In equation/inequation JSON, both leftExpression and rightExpression are TypeClause slots — always wrap the real Expression in a NormalTypeClause (normalType child holds the actual Expression). Do not put the Expression directly under leftExpression/rightExpression.
• TextGen-style dispatch caveat does not apply here; typesystem rules are inherited via concept hierarchy, but the overrides property on a rule suppresses inherited rules from superconcepts.
• TextGen / typesystem error messages: wrap smodel expressions that render types with <...> presentation: error "Expected " + <expectedType> + " but got " + <actualType> -> node;. Avoid raw toString.
• when concrete (typeof(expr) as v) { ... } defers a block until the type is fully resolved — use it before deciding whether to report an error or assign a result type.
• Quick fixes (TypesystemQuickFix) are roots, not executed automatically — the user triggers them via the UI. Wire them into a report through the helginsIntention slot (TypesystemIntention wrapper with quickFix ref + actualArguments). See references/quick-fixes.md.
• Reusable helper code (utility classes, shared algorithms) can live as a plain BaseLanguage ClassConcept root directly in the typesystem model. No separate utility module is required.
• For MPS-typed return types (sequence<node<X>>, list<node<X>>) the Java parser gives back List<SNode> — fix per references/variable-declarations.md in the mps-model-manipulation skill root after loading that companion skill from the same origin.
• Edit typesystem 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.
• After edits run mps_mcp_check_root_node_problems, compile the language, and test on sample models.