MPS: Skill for Claude Code

MPS TextGen 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.

TextGen turns a model (usually the output of generation) into plain text files. It is how BaseLanguage becomes .java on disk, and how any text-targeting language serialises its models. Lives in <lang>/languageModels/textGen.mps, language jetbrains.mps.lang.textGen. Rule bodies are BaseLanguage + smodel + textgen-specific statements (append, indent buffer, with indent).

Prerequisite for any insert: the textGen model must exist (mps_mcp_create_model with moduleName: "<lang>" and modelName: "<lang>.textGen" — aspect ID textGen, case-sensitive, no @ suffix; see aspect-model-stereotypes.md) and must import jetbrains.mps.lang.textGen, jetbrains.mps.baseLanguage, and jetbrains.mps.lang.smodel as used languages before the first mps_mcp_insert_root_node_from_json. Missing any of these three causes node inserts to fail with unresolved-concept errors. See step 1 of the Common-Path Workflow.

Critical Directives

• One ConceptTextGenDeclaration root per concept you want to serialise. Only the file-generating root concept needs extension / filename / encoding; structural concepts inside the file need only textGenBlock.
• extension is a function body returning a string, not a literal property. It must return a string.
• TextGen dispatch is concept-exact, not polymorphic. An extending concept that wants the parent's serialisation must declare its own ConceptTextGenDeclaration (even an empty one) — or its output will be silently missing. See references/dispatch-and-base-component.md.
• The indentation buffer is a per-output-file depth counter. with indent / increase depth / decrease depth and the withIndent flag on NodeAppendPart only mutate the counter — whitespace is emitted only when indent buffer is called. Always pair append \n ; with indent buffer ; on the next line that should be indented. See references/indentation-model.md.
• Prefer with indent { ... } over paired increase depth ; … ; decrease depth ; — the block form cannot leak depth on an early return or exception. Use the paired form only when the scope is not a block.
• Use TextGen only when the final artifact is text. If your pipeline ends in a model-to-model transformation targeting another MPS language (e.g. BaseLanguage), you don't need TextGen — that language's own TextGen handles the final step.
• BinaryWriteOperation (write) cannot be mixed with text appends in the same ConceptTextGenDeclaration. A rule emits either text or bytes, not both.
• The older $ref{node.reference<target>} syntax is deprecated. Use a NodeAppendPart over a resolved node (or over .name).
• Edit textGen models through MPS MCP tools (mps_mcp_insert_root_node_from_json, mps_mcp_update_node). Do not hand-edit .mps files.
• After edits run mps_mcp_check_root_node_problems and rebuild the language; regenerate consumers.