[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill-jetbrains-mps-language-modularity":3,"mdc--thq7v7-key":32,"related-org-jetbrains-mps-language-modularity":1058,"related-repo-jetbrains-mps-language-modularity":1185},{"slug":4,"name":4,"fn":5,"description":6,"org":7,"tags":11,"stars":19,"repoUrl":20,"updatedAt":21,"license":22,"forks":23,"topics":24,"repo":27,"sourceUrl":30,"mdContent":31},"mps-language-modularity","design MPS language modularity and composition","Use when designing how multiple MPS languages relate or compose — choosing between language referencing, extension, reuse, and embedding, or deciding where a cross-language dependency should live and how generated code interacts. Covers the 2×2 modularity taxonomy adapted to MPS, a decision procedure, per-kind recipes (references + search scopes; subconcepting + overloaded operations; abstract hooks + adapter languages + separated\u002Finterwoven generation; guest + composition languages + type bridges), the annotations escape hatch, and per-kind validation. This is the design tier above the aspect-implementation skills: it picks the strategy, then routes into the relevant mps-aspect-* skills (structure, constraints, typesystem, generator, generation-plan, intentions) and mps-tests. Reach for it before authoring aspects, or whenever one language must see, extend, embed, or adapt another.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},"jetbrains","JetBrains","https:\u002F\u002Fpexgzepcugksgbtrxkhf.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Forg-logos\u002Fjetbrains.png",[12,16],{"name":13,"slug":14,"type":15},"Architecture","architecture","tag",{"name":17,"slug":18,"type":15},"System Design","system-design",1650,"https:\u002F\u002Fgithub.com\u002FJetBrains\u002FMPS","2026-07-17T06:06:53.102242",null,311,[25,26],"domain-specific-language","dsl",{"repoUrl":20,"stars":19,"forks":23,"topics":28,"description":29},[25,26],"JetBrains Meta programming System","https:\u002F\u002Fgithub.com\u002FJetBrains\u002FMPS\u002Ftree\u002FHEAD\u002Fplugins\u002Fmcp-tools\u002Fresources\u002Fjetbrains\u002Fmps\u002Fagents\u002Fmcp\u002Fskills\u002Fmps-language-modularity","---\nname: mps-language-modularity\ndescription: >-\n  Use when designing how multiple MPS languages relate or compose — choosing between language referencing, extension, reuse, and embedding, or deciding where a cross-language dependency should live and how generated code interacts. Covers the 2×2 modularity taxonomy adapted to MPS, a decision procedure, per-kind recipes (references + search scopes; subconcepting + overloaded operations; abstract hooks + adapter languages + separated\u002Finterwoven generation; guest + composition languages + type bridges), the annotations escape hatch, and per-kind validation. This is the design tier above the aspect-implementation skills: it picks the strategy, then routes into the relevant mps-aspect-* skills (structure, constraints, typesystem, generator, generation-plan, intentions) and mps-tests. Reach for it before authoring aspects, or whenever one language must see, extend, embed, or adapt another.\ntype: reference\n---\n\n# MPS Language Modularity & Composition\n\nThe **design tier** for multi-language MPS work: before authoring aspects, decide *how* the languages relate. This skill turns a 2×2 taxonomy into a decision procedure and routes each choice into the aspect skills that implement it.\n\n**The MPS-specific lesson: syntax composition is the easy part.** MPS is projectional — no parser, no grammar to become ambiguous — so combining notations needs far less work than in parser-based tools (only alias clashes and completion UX still need a glance). The real difficulty is semantic: **scopes, type systems, generator contracts, and migration.** Choosing a modularity kind is mostly choosing *where the dependency lives* and *how generated code interacts*.\n\n## Critical directives\n\n- **Spend effort on semantics, not syntax.** Scopes, type bridges, generator contracts, and migration are where modular languages break.\n- **Two questions decide the kind** (below). Answer them before touching any aspect.\n- **MPS \"extends\" ≠ the design category.** At the module level MPS calls almost any inter-language use \"extension\"; that *tool-level* dependency is independent of whether your *design* is referencing\u002Fextension\u002Freuse\u002Fembedding. See `references\u002Fdesign-principles.md`.\n- **References vs. containment is the structural fork.** Model a foreign element as a **reference** → *referencing*. Contain a foreign concept as a **child** → inline composition (*extension* vs *embedding*). Hard to reverse — pick deliberately.\n- **Reuse must be designed in.** Abstract hooks, behavior contracts, and generator placeholders must exist *before* you need them; after-the-fact reuse (especially interwoven generation) is severely limited.\n- **The exported surface is an API.** Behavior-method names, interface concepts, placeholder IDs, mapping labels, and generated abstract signatures are cross-language contracts — stabilize, version, and test them.\n\n## The two questions (the 2×2)\n\n> The four-kind taxonomy (referencing \u002F extension \u002F reuse \u002F embedding) was introduced by **Markus Voelter** in his work on language composition (*DSL Engineering*). This skill adapts it to MPS practice.\n\n|                                           | **New language MAY depend on the other** | **New language may NOT depend (independent core)** |\n|-------------------------------------------|------------------------------------------|----------------------------------------------------|\n| **Separate fragments** (no inline syntax) | **Referencing**                          | **Reuse** (via an adapter language)                |\n| **Same fragment** (inline syntax)         | **Extension**                            | **Embedding** (via a composition language)         |\n\n> \"Inline \u002F same fragment\" means the concrete syntax the user *writes* — not where generated code ends up. Whether generated code is physically inlined is a *separate* axis (separated-vs-interwoven within **Reuse**), orthogonal to the kind.\n\n## Decision procedure\n\n1. **Must the new constructs be written inline**, among the host's nodes in the same fragment\u002Froot?\n   - **No** → step 2.  **Yes** → step 3.\n2. *(separate fragments)* **May the new language know the other directly?**\n   - **Yes** → **Referencing** — cross-language references + search scopes.\n   - **No** → **Reuse** — keep the core independent; build a separate **adapter** language that depends on both.\n3. *(inline syntax)* **Are the new constructs built specifically for this host, or do they come from a language that must stay independent (a reusable guest)?**\n   - **Built for the host, may depend on it** → **Extension** — subconcept the host's concepts; integrate type rules and generators additively.\n   - **Must stay independent** → **Embedding** — add a third **composition** language depending on both host and guest, so neither needs to know the other.\n\nIf the goal is only to **attach metadata** to existing nodes (traceability, variability) rather than compose semantics, none of the four applies — see the **annotations** escape hatch in `references\u002Fdesign-principles.md`.\n\n## The four kinds — essence, mechanism, routing\n\n| Kind | One-liner | Inline? | Core dependency | Typical MPS mechanism | Generated-code relation | Implement with |\n|---|---|---|---|---|---|---|\n| **Referencing** | New language points into another's nodes; fragments stay separate (a dashboard widget → a metric in a catalog) | No | Yes | Cross-language references + search scopes + behavior naming contracts | Separate generators, shared naming contracts | structure-concepts, constraints, behavior |\n| **Extension** | New concepts subtype base concepts, legal wherever the base is (MPS's own `collections`\u002F`closures` over BaseLanguage) | Yes | Yes | Subconcept base concepts; additive typesystem (overloaded operations); reduction\u002Fweaving assimilation | Assimilated into the base language | structure-concepts, typesystem, generator, intentions |\n| **Reuse** | Independently valuable core exposing hooks an adapter fills (a state-machine core whose `Guard`\u002F`Action` an adapter binds) | No (in core) | No in core; yes in adapter | Abstract hook concepts + abstract behavior; separate adapter language; generator placeholders\u002Fpriorities | Separated *or* interwoven | structure-concepts, behavior, generator, generation-plan |\n| **Embedding** | Independent guest dropped inline in a host; a composition language bridges (an expression language inside a business rule) | Yes | Host\u002Fguest independent; composition layer depends on both | Host owns a child of guest's abstract concept + scope\u002Ftype\u002Fgenerator adapters | Reuses guest generator; host-specific reductions | constraints, typesystem, generator, intentions |\n\nIf you don't actually need the guest to stay independent, **extension is materially cheaper than embedding** — prefer it.\n\nWiring the dependencies any strategy needs (used\u002Fextended languages, runtime solutions, accessory models) is [`mps-aspect-accessories`](..\u002Fmps-aspect-accessories\u002FSKILL.md). Aspect-skill links above are under `..\u002Fmps-aspect-*\u002FSKILL.md`.\n\n## Reference index\n\n- `references\u002Freferencing.md` — reference links, smart references, search scopes, behavior naming contracts.\n- `references\u002Fextension.md` — subconcepting, overloaded operations, assimilation\u002Fweaving generators, placeholder hooks, upgrade intentions.\n- `references\u002Freuse.md` — abstract hooks, abstract behavior contracts, adapter languages, separated-vs-interwoven generation.\n- `references\u002Fembedding.md` — composition language, narrow scopes, host\u002Fguest type bridges, reusing the guest's lowering pipeline.\n- `references\u002Fdesign-principles.md` — cross-cutting lessons (reuse-designed-in, behavior contracts, specific references, model-to-model assimilation, MPS-\"extends\" trap) and the **annotations** escape hatch.\n- `references\u002Fvalidation.md` — the per-kind test checklist.\n\n## Related skills\n\n- [`mps-language-aspects-overview`](..\u002Fmps-language-aspects-overview\u002FSKILL.md) — authoring order and which aspect to edit once a strategy is chosen.\n- [`mps-language-inheritance`](..\u002Fmps-language-inheritance\u002FSKILL.md) — module `extends` and concept super\u002Fsub mechanics used by extension and embedding.\n- [`mps-tests`](..\u002Fmps-tests\u002FSKILL.md) — `NodesTestCase` \u002F `EditorTestCase` patterns the validation checklist relies on.\n\n## Validation\n\nProjectional reality changes what to test: invalid syntax usually cannot be entered, so parser-style tests are nearly irrelevant. Test the **semantic seams** — visible vs. invisible scope targets, host\u002Fguest type bridges, generator contracts (placeholder IDs, abstract signatures, priorities), and migration of representative example models. Run the model checker over the example suite after every structural or generator change. Full per-kind checklist: `references\u002Fvalidation.md`.\n\n> Code snippets here are **illustrative pseudo-syntax** showing the *shape* of each pattern — implement the real artifacts through MPS MCP tools and the linked aspect skills; never hand-edit `.mps` files.\n",{"data":33,"body":35},{"name":4,"description":6,"type":34},"reference",{"type":36,"children":37},"root",[38,47,69,100,107,235,241,264,363,391,397,538,563,569,809,821,846,852,926,932,1004,1010,1028],{"type":39,"tag":40,"props":41,"children":43},"element","h1",{"id":42},"mps-language-modularity-composition",[44],{"type":45,"value":46},"text","MPS Language Modularity & Composition",{"type":39,"tag":48,"props":49,"children":50},"p",{},[51,53,59,61,67],{"type":45,"value":52},"The ",{"type":39,"tag":54,"props":55,"children":56},"strong",{},[57],{"type":45,"value":58},"design tier",{"type":45,"value":60}," for multi-language MPS work: before authoring aspects, decide ",{"type":39,"tag":62,"props":63,"children":64},"em",{},[65],{"type":45,"value":66},"how",{"type":45,"value":68}," the languages relate. This skill turns a 2×2 taxonomy into a decision procedure and routes each choice into the aspect skills that implement it.",{"type":39,"tag":48,"props":70,"children":71},{},[72,77,79,84,86,91,93,98],{"type":39,"tag":54,"props":73,"children":74},{},[75],{"type":45,"value":76},"The MPS-specific lesson: syntax composition is the easy part.",{"type":45,"value":78}," MPS is projectional — no parser, no grammar to become ambiguous — so combining notations needs far less work than in parser-based tools (only alias clashes and completion UX still need a glance). The real difficulty is semantic: ",{"type":39,"tag":54,"props":80,"children":81},{},[82],{"type":45,"value":83},"scopes, type systems, generator contracts, and migration.",{"type":45,"value":85}," Choosing a modularity kind is mostly choosing ",{"type":39,"tag":62,"props":87,"children":88},{},[89],{"type":45,"value":90},"where the dependency lives",{"type":45,"value":92}," and ",{"type":39,"tag":62,"props":94,"children":95},{},[96],{"type":45,"value":97},"how generated code interacts",{"type":45,"value":99},".",{"type":39,"tag":101,"props":102,"children":104},"h2",{"id":103},"critical-directives",[105],{"type":45,"value":106},"Critical directives",{"type":39,"tag":108,"props":109,"children":110},"ul",{},[111,122,132,164,208,225],{"type":39,"tag":112,"props":113,"children":114},"li",{},[115,120],{"type":39,"tag":54,"props":116,"children":117},{},[118],{"type":45,"value":119},"Spend effort on semantics, not syntax.",{"type":45,"value":121}," Scopes, type bridges, generator contracts, and migration are where modular languages break.",{"type":39,"tag":112,"props":123,"children":124},{},[125,130],{"type":39,"tag":54,"props":126,"children":127},{},[128],{"type":45,"value":129},"Two questions decide the kind",{"type":45,"value":131}," (below). Answer them before touching any aspect.",{"type":39,"tag":112,"props":133,"children":134},{},[135,140,142,147,149,154,156,163],{"type":39,"tag":54,"props":136,"children":137},{},[138],{"type":45,"value":139},"MPS \"extends\" ≠ the design category.",{"type":45,"value":141}," At the module level MPS calls almost any inter-language use \"extension\"; that ",{"type":39,"tag":62,"props":143,"children":144},{},[145],{"type":45,"value":146},"tool-level",{"type":45,"value":148}," dependency is independent of whether your ",{"type":39,"tag":62,"props":150,"children":151},{},[152],{"type":45,"value":153},"design",{"type":45,"value":155}," is referencing\u002Fextension\u002Freuse\u002Fembedding. See ",{"type":39,"tag":157,"props":158,"children":160},"code",{"className":159},[],[161],{"type":45,"value":162},"references\u002Fdesign-principles.md",{"type":45,"value":99},{"type":39,"tag":112,"props":165,"children":166},{},[167,172,174,178,180,185,187,192,194,199,201,206],{"type":39,"tag":54,"props":168,"children":169},{},[170],{"type":45,"value":171},"References vs. containment is the structural fork.",{"type":45,"value":173}," Model a foreign element as a ",{"type":39,"tag":54,"props":175,"children":176},{},[177],{"type":45,"value":34},{"type":45,"value":179}," → ",{"type":39,"tag":62,"props":181,"children":182},{},[183],{"type":45,"value":184},"referencing",{"type":45,"value":186},". Contain a foreign concept as a ",{"type":39,"tag":54,"props":188,"children":189},{},[190],{"type":45,"value":191},"child",{"type":45,"value":193}," → inline composition (",{"type":39,"tag":62,"props":195,"children":196},{},[197],{"type":45,"value":198},"extension",{"type":45,"value":200}," vs ",{"type":39,"tag":62,"props":202,"children":203},{},[204],{"type":45,"value":205},"embedding",{"type":45,"value":207},"). Hard to reverse — pick deliberately.",{"type":39,"tag":112,"props":209,"children":210},{},[211,216,218,223],{"type":39,"tag":54,"props":212,"children":213},{},[214],{"type":45,"value":215},"Reuse must be designed in.",{"type":45,"value":217}," Abstract hooks, behavior contracts, and generator placeholders must exist ",{"type":39,"tag":62,"props":219,"children":220},{},[221],{"type":45,"value":222},"before",{"type":45,"value":224}," you need them; after-the-fact reuse (especially interwoven generation) is severely limited.",{"type":39,"tag":112,"props":226,"children":227},{},[228,233],{"type":39,"tag":54,"props":229,"children":230},{},[231],{"type":45,"value":232},"The exported surface is an API.",{"type":45,"value":234}," Behavior-method names, interface concepts, placeholder IDs, mapping labels, and generated abstract signatures are cross-language contracts — stabilize, version, and test them.",{"type":39,"tag":101,"props":236,"children":238},{"id":237},"the-two-questions-the-22",[239],{"type":45,"value":240},"The two questions (the 2×2)",{"type":39,"tag":242,"props":243,"children":244},"blockquote",{},[245],{"type":39,"tag":48,"props":246,"children":247},{},[248,250,255,257,262],{"type":45,"value":249},"The four-kind taxonomy (referencing \u002F extension \u002F reuse \u002F embedding) was introduced by ",{"type":39,"tag":54,"props":251,"children":252},{},[253],{"type":45,"value":254},"Markus Voelter",{"type":45,"value":256}," in his work on language composition (",{"type":39,"tag":62,"props":258,"children":259},{},[260],{"type":45,"value":261},"DSL Engineering",{"type":45,"value":263},"). This skill adapts it to MPS practice.",{"type":39,"tag":265,"props":266,"children":267},"table",{},[268,296],{"type":39,"tag":269,"props":270,"children":271},"thead",{},[272],{"type":39,"tag":273,"props":274,"children":275},"tr",{},[276,280,288],{"type":39,"tag":277,"props":278,"children":279},"th",{},[],{"type":39,"tag":277,"props":281,"children":282},{},[283],{"type":39,"tag":54,"props":284,"children":285},{},[286],{"type":45,"value":287},"New language MAY depend on the other",{"type":39,"tag":277,"props":289,"children":290},{},[291],{"type":39,"tag":54,"props":292,"children":293},{},[294],{"type":45,"value":295},"New language may NOT depend (independent core)",{"type":39,"tag":297,"props":298,"children":299},"tbody",{},[300,332],{"type":39,"tag":273,"props":301,"children":302},{},[303,314,322],{"type":39,"tag":304,"props":305,"children":306},"td",{},[307,312],{"type":39,"tag":54,"props":308,"children":309},{},[310],{"type":45,"value":311},"Separate fragments",{"type":45,"value":313}," (no inline syntax)",{"type":39,"tag":304,"props":315,"children":316},{},[317],{"type":39,"tag":54,"props":318,"children":319},{},[320],{"type":45,"value":321},"Referencing",{"type":39,"tag":304,"props":323,"children":324},{},[325,330],{"type":39,"tag":54,"props":326,"children":327},{},[328],{"type":45,"value":329},"Reuse",{"type":45,"value":331}," (via an adapter language)",{"type":39,"tag":273,"props":333,"children":334},{},[335,345,353],{"type":39,"tag":304,"props":336,"children":337},{},[338,343],{"type":39,"tag":54,"props":339,"children":340},{},[341],{"type":45,"value":342},"Same fragment",{"type":45,"value":344}," (inline syntax)",{"type":39,"tag":304,"props":346,"children":347},{},[348],{"type":39,"tag":54,"props":349,"children":350},{},[351],{"type":45,"value":352},"Extension",{"type":39,"tag":304,"props":354,"children":355},{},[356,361],{"type":39,"tag":54,"props":357,"children":358},{},[359],{"type":45,"value":360},"Embedding",{"type":45,"value":362}," (via a composition language)",{"type":39,"tag":242,"props":364,"children":365},{},[366],{"type":39,"tag":48,"props":367,"children":368},{},[369,371,376,378,383,385,389],{"type":45,"value":370},"\"Inline \u002F same fragment\" means the concrete syntax the user ",{"type":39,"tag":62,"props":372,"children":373},{},[374],{"type":45,"value":375},"writes",{"type":45,"value":377}," — not where generated code ends up. Whether generated code is physically inlined is a ",{"type":39,"tag":62,"props":379,"children":380},{},[381],{"type":45,"value":382},"separate",{"type":45,"value":384}," axis (separated-vs-interwoven within ",{"type":39,"tag":54,"props":386,"children":387},{},[388],{"type":45,"value":329},{"type":45,"value":390},"), orthogonal to the kind.",{"type":39,"tag":101,"props":392,"children":394},{"id":393},"decision-procedure",[395],{"type":45,"value":396},"Decision procedure",{"type":39,"tag":398,"props":399,"children":400},"ol",{},[401,431,484],{"type":39,"tag":112,"props":402,"children":403},{},[404,409,411],{"type":39,"tag":54,"props":405,"children":406},{},[407],{"type":45,"value":408},"Must the new constructs be written inline",{"type":45,"value":410},", among the host's nodes in the same fragment\u002Froot?\n",{"type":39,"tag":108,"props":412,"children":413},{},[414],{"type":39,"tag":112,"props":415,"children":416},{},[417,422,424,429],{"type":39,"tag":54,"props":418,"children":419},{},[420],{"type":45,"value":421},"No",{"type":45,"value":423}," → step 2.  ",{"type":39,"tag":54,"props":425,"children":426},{},[427],{"type":45,"value":428},"Yes",{"type":45,"value":430}," → step 3.",{"type":39,"tag":112,"props":432,"children":433},{},[434,439,441,446],{"type":39,"tag":62,"props":435,"children":436},{},[437],{"type":45,"value":438},"(separate fragments)",{"type":45,"value":440}," ",{"type":39,"tag":54,"props":442,"children":443},{},[444],{"type":45,"value":445},"May the new language know the other directly?",{"type":39,"tag":108,"props":447,"children":448},{},[449,463],{"type":39,"tag":112,"props":450,"children":451},{},[452,456,457,461],{"type":39,"tag":54,"props":453,"children":454},{},[455],{"type":45,"value":428},{"type":45,"value":179},{"type":39,"tag":54,"props":458,"children":459},{},[460],{"type":45,"value":321},{"type":45,"value":462}," — cross-language references + search scopes.",{"type":39,"tag":112,"props":464,"children":465},{},[466,470,471,475,477,482],{"type":39,"tag":54,"props":467,"children":468},{},[469],{"type":45,"value":421},{"type":45,"value":179},{"type":39,"tag":54,"props":472,"children":473},{},[474],{"type":45,"value":329},{"type":45,"value":476}," — keep the core independent; build a separate ",{"type":39,"tag":54,"props":478,"children":479},{},[480],{"type":45,"value":481},"adapter",{"type":45,"value":483}," language that depends on both.",{"type":39,"tag":112,"props":485,"children":486},{},[487,492,493,498],{"type":39,"tag":62,"props":488,"children":489},{},[490],{"type":45,"value":491},"(inline syntax)",{"type":45,"value":440},{"type":39,"tag":54,"props":494,"children":495},{},[496],{"type":45,"value":497},"Are the new constructs built specifically for this host, or do they come from a language that must stay independent (a reusable guest)?",{"type":39,"tag":108,"props":499,"children":500},{},[501,516],{"type":39,"tag":112,"props":502,"children":503},{},[504,509,510,514],{"type":39,"tag":54,"props":505,"children":506},{},[507],{"type":45,"value":508},"Built for the host, may depend on it",{"type":45,"value":179},{"type":39,"tag":54,"props":511,"children":512},{},[513],{"type":45,"value":352},{"type":45,"value":515}," — subconcept the host's concepts; integrate type rules and generators additively.",{"type":39,"tag":112,"props":517,"children":518},{},[519,524,525,529,531,536],{"type":39,"tag":54,"props":520,"children":521},{},[522],{"type":45,"value":523},"Must stay independent",{"type":45,"value":179},{"type":39,"tag":54,"props":526,"children":527},{},[528],{"type":45,"value":360},{"type":45,"value":530}," — add a third ",{"type":39,"tag":54,"props":532,"children":533},{},[534],{"type":45,"value":535},"composition",{"type":45,"value":537}," language depending on both host and guest, so neither needs to know the other.",{"type":39,"tag":48,"props":539,"children":540},{},[541,543,548,550,555,557,562],{"type":45,"value":542},"If the goal is only to ",{"type":39,"tag":54,"props":544,"children":545},{},[546],{"type":45,"value":547},"attach metadata",{"type":45,"value":549}," to existing nodes (traceability, variability) rather than compose semantics, none of the four applies — see the ",{"type":39,"tag":54,"props":551,"children":552},{},[553],{"type":45,"value":554},"annotations",{"type":45,"value":556}," escape hatch in ",{"type":39,"tag":157,"props":558,"children":560},{"className":559},[],[561],{"type":45,"value":162},{"type":45,"value":99},{"type":39,"tag":101,"props":564,"children":566},{"id":565},"the-four-kinds-essence-mechanism-routing",[567],{"type":45,"value":568},"The four kinds — essence, mechanism, routing",{"type":39,"tag":265,"props":570,"children":571},{},[572,613],{"type":39,"tag":269,"props":573,"children":574},{},[575],{"type":39,"tag":273,"props":576,"children":577},{},[578,583,588,593,598,603,608],{"type":39,"tag":277,"props":579,"children":580},{},[581],{"type":45,"value":582},"Kind",{"type":39,"tag":277,"props":584,"children":585},{},[586],{"type":45,"value":587},"One-liner",{"type":39,"tag":277,"props":589,"children":590},{},[591],{"type":45,"value":592},"Inline?",{"type":39,"tag":277,"props":594,"children":595},{},[596],{"type":45,"value":597},"Core dependency",{"type":39,"tag":277,"props":599,"children":600},{},[601],{"type":45,"value":602},"Typical MPS mechanism",{"type":39,"tag":277,"props":604,"children":605},{},[606],{"type":45,"value":607},"Generated-code relation",{"type":39,"tag":277,"props":609,"children":610},{},[611],{"type":45,"value":612},"Implement with",{"type":39,"tag":297,"props":614,"children":615},{},[616,654,708,770],{"type":39,"tag":273,"props":617,"children":618},{},[619,626,631,635,639,644,649],{"type":39,"tag":304,"props":620,"children":621},{},[622],{"type":39,"tag":54,"props":623,"children":624},{},[625],{"type":45,"value":321},{"type":39,"tag":304,"props":627,"children":628},{},[629],{"type":45,"value":630},"New language points into another's nodes; fragments stay separate (a dashboard widget → a metric in a catalog)",{"type":39,"tag":304,"props":632,"children":633},{},[634],{"type":45,"value":421},{"type":39,"tag":304,"props":636,"children":637},{},[638],{"type":45,"value":428},{"type":39,"tag":304,"props":640,"children":641},{},[642],{"type":45,"value":643},"Cross-language references + search scopes + behavior naming contracts",{"type":39,"tag":304,"props":645,"children":646},{},[647],{"type":45,"value":648},"Separate generators, shared naming contracts",{"type":39,"tag":304,"props":650,"children":651},{},[652],{"type":45,"value":653},"structure-concepts, constraints, behavior",{"type":39,"tag":273,"props":655,"children":656},{},[657,664,685,689,693,698,703],{"type":39,"tag":304,"props":658,"children":659},{},[660],{"type":39,"tag":54,"props":661,"children":662},{},[663],{"type":45,"value":352},{"type":39,"tag":304,"props":665,"children":666},{},[667,669,675,677,683],{"type":45,"value":668},"New concepts subtype base concepts, legal wherever the base is (MPS's own ",{"type":39,"tag":157,"props":670,"children":672},{"className":671},[],[673],{"type":45,"value":674},"collections",{"type":45,"value":676},"\u002F",{"type":39,"tag":157,"props":678,"children":680},{"className":679},[],[681],{"type":45,"value":682},"closures",{"type":45,"value":684}," over BaseLanguage)",{"type":39,"tag":304,"props":686,"children":687},{},[688],{"type":45,"value":428},{"type":39,"tag":304,"props":690,"children":691},{},[692],{"type":45,"value":428},{"type":39,"tag":304,"props":694,"children":695},{},[696],{"type":45,"value":697},"Subconcept base concepts; additive typesystem (overloaded operations); reduction\u002Fweaving assimilation",{"type":39,"tag":304,"props":699,"children":700},{},[701],{"type":45,"value":702},"Assimilated into the base language",{"type":39,"tag":304,"props":704,"children":705},{},[706],{"type":45,"value":707},"structure-concepts, typesystem, generator, intentions",{"type":39,"tag":273,"props":709,"children":710},{},[711,718,738,743,748,753,765],{"type":39,"tag":304,"props":712,"children":713},{},[714],{"type":39,"tag":54,"props":715,"children":716},{},[717],{"type":45,"value":329},{"type":39,"tag":304,"props":719,"children":720},{},[721,723,729,730,736],{"type":45,"value":722},"Independently valuable core exposing hooks an adapter fills (a state-machine core whose ",{"type":39,"tag":157,"props":724,"children":726},{"className":725},[],[727],{"type":45,"value":728},"Guard",{"type":45,"value":676},{"type":39,"tag":157,"props":731,"children":733},{"className":732},[],[734],{"type":45,"value":735},"Action",{"type":45,"value":737}," an adapter binds)",{"type":39,"tag":304,"props":739,"children":740},{},[741],{"type":45,"value":742},"No (in core)",{"type":39,"tag":304,"props":744,"children":745},{},[746],{"type":45,"value":747},"No in core; yes in adapter",{"type":39,"tag":304,"props":749,"children":750},{},[751],{"type":45,"value":752},"Abstract hook concepts + abstract behavior; separate adapter language; generator placeholders\u002Fpriorities",{"type":39,"tag":304,"props":754,"children":755},{},[756,758,763],{"type":45,"value":757},"Separated ",{"type":39,"tag":62,"props":759,"children":760},{},[761],{"type":45,"value":762},"or",{"type":45,"value":764}," interwoven",{"type":39,"tag":304,"props":766,"children":767},{},[768],{"type":45,"value":769},"structure-concepts, behavior, generator, generation-plan",{"type":39,"tag":273,"props":771,"children":772},{},[773,780,785,789,794,799,804],{"type":39,"tag":304,"props":774,"children":775},{},[776],{"type":39,"tag":54,"props":777,"children":778},{},[779],{"type":45,"value":360},{"type":39,"tag":304,"props":781,"children":782},{},[783],{"type":45,"value":784},"Independent guest dropped inline in a host; a composition language bridges (an expression language inside a business rule)",{"type":39,"tag":304,"props":786,"children":787},{},[788],{"type":45,"value":428},{"type":39,"tag":304,"props":790,"children":791},{},[792],{"type":45,"value":793},"Host\u002Fguest independent; composition layer depends on both",{"type":39,"tag":304,"props":795,"children":796},{},[797],{"type":45,"value":798},"Host owns a child of guest's abstract concept + scope\u002Ftype\u002Fgenerator adapters",{"type":39,"tag":304,"props":800,"children":801},{},[802],{"type":45,"value":803},"Reuses guest generator; host-specific reductions",{"type":39,"tag":304,"props":805,"children":806},{},[807],{"type":45,"value":808},"constraints, typesystem, generator, intentions",{"type":39,"tag":48,"props":810,"children":811},{},[812,814,819],{"type":45,"value":813},"If you don't actually need the guest to stay independent, ",{"type":39,"tag":54,"props":815,"children":816},{},[817],{"type":45,"value":818},"extension is materially cheaper than embedding",{"type":45,"value":820}," — prefer it.",{"type":39,"tag":48,"props":822,"children":823},{},[824,826,837,839,845],{"type":45,"value":825},"Wiring the dependencies any strategy needs (used\u002Fextended languages, runtime solutions, accessory models) is ",{"type":39,"tag":827,"props":828,"children":830},"a",{"href":829},"..\u002Fmps-aspect-accessories\u002FSKILL.md",[831],{"type":39,"tag":157,"props":832,"children":834},{"className":833},[],[835],{"type":45,"value":836},"mps-aspect-accessories",{"type":45,"value":838},". Aspect-skill links above are under ",{"type":39,"tag":157,"props":840,"children":842},{"className":841},[],[843],{"type":45,"value":844},"..\u002Fmps-aspect-*\u002FSKILL.md",{"type":45,"value":99},{"type":39,"tag":101,"props":847,"children":849},{"id":848},"reference-index",[850],{"type":45,"value":851},"Reference index",{"type":39,"tag":108,"props":853,"children":854},{},[855,866,877,888,899,915],{"type":39,"tag":112,"props":856,"children":857},{},[858,864],{"type":39,"tag":157,"props":859,"children":861},{"className":860},[],[862],{"type":45,"value":863},"references\u002Freferencing.md",{"type":45,"value":865}," — reference links, smart references, search scopes, behavior naming contracts.",{"type":39,"tag":112,"props":867,"children":868},{},[869,875],{"type":39,"tag":157,"props":870,"children":872},{"className":871},[],[873],{"type":45,"value":874},"references\u002Fextension.md",{"type":45,"value":876}," — subconcepting, overloaded operations, assimilation\u002Fweaving generators, placeholder hooks, upgrade intentions.",{"type":39,"tag":112,"props":878,"children":879},{},[880,886],{"type":39,"tag":157,"props":881,"children":883},{"className":882},[],[884],{"type":45,"value":885},"references\u002Freuse.md",{"type":45,"value":887}," — abstract hooks, abstract behavior contracts, adapter languages, separated-vs-interwoven generation.",{"type":39,"tag":112,"props":889,"children":890},{},[891,897],{"type":39,"tag":157,"props":892,"children":894},{"className":893},[],[895],{"type":45,"value":896},"references\u002Fembedding.md",{"type":45,"value":898}," — composition language, narrow scopes, host\u002Fguest type bridges, reusing the guest's lowering pipeline.",{"type":39,"tag":112,"props":900,"children":901},{},[902,907,909,913],{"type":39,"tag":157,"props":903,"children":905},{"className":904},[],[906],{"type":45,"value":162},{"type":45,"value":908}," — cross-cutting lessons (reuse-designed-in, behavior contracts, specific references, model-to-model assimilation, MPS-\"extends\" trap) and the ",{"type":39,"tag":54,"props":910,"children":911},{},[912],{"type":45,"value":554},{"type":45,"value":914}," escape hatch.",{"type":39,"tag":112,"props":916,"children":917},{},[918,924],{"type":39,"tag":157,"props":919,"children":921},{"className":920},[],[922],{"type":45,"value":923},"references\u002Fvalidation.md",{"type":45,"value":925}," — the per-kind test checklist.",{"type":39,"tag":101,"props":927,"children":929},{"id":928},"related-skills",[930],{"type":45,"value":931},"Related skills",{"type":39,"tag":108,"props":933,"children":934},{},[935,950,973],{"type":39,"tag":112,"props":936,"children":937},{},[938,948],{"type":39,"tag":827,"props":939,"children":941},{"href":940},"..\u002Fmps-language-aspects-overview\u002FSKILL.md",[942],{"type":39,"tag":157,"props":943,"children":945},{"className":944},[],[946],{"type":45,"value":947},"mps-language-aspects-overview",{"type":45,"value":949}," — authoring order and which aspect to edit once a strategy is chosen.",{"type":39,"tag":112,"props":951,"children":952},{},[953,963,965,971],{"type":39,"tag":827,"props":954,"children":956},{"href":955},"..\u002Fmps-language-inheritance\u002FSKILL.md",[957],{"type":39,"tag":157,"props":958,"children":960},{"className":959},[],[961],{"type":45,"value":962},"mps-language-inheritance",{"type":45,"value":964}," — module ",{"type":39,"tag":157,"props":966,"children":968},{"className":967},[],[969],{"type":45,"value":970},"extends",{"type":45,"value":972}," and concept super\u002Fsub mechanics used by extension and embedding.",{"type":39,"tag":112,"props":974,"children":975},{},[976,986,988,994,996,1002],{"type":39,"tag":827,"props":977,"children":979},{"href":978},"..\u002Fmps-tests\u002FSKILL.md",[980],{"type":39,"tag":157,"props":981,"children":983},{"className":982},[],[984],{"type":45,"value":985},"mps-tests",{"type":45,"value":987}," — ",{"type":39,"tag":157,"props":989,"children":991},{"className":990},[],[992],{"type":45,"value":993},"NodesTestCase",{"type":45,"value":995}," \u002F ",{"type":39,"tag":157,"props":997,"children":999},{"className":998},[],[1000],{"type":45,"value":1001},"EditorTestCase",{"type":45,"value":1003}," patterns the validation checklist relies on.",{"type":39,"tag":101,"props":1005,"children":1007},{"id":1006},"validation",[1008],{"type":45,"value":1009},"Validation",{"type":39,"tag":48,"props":1011,"children":1012},{},[1013,1015,1020,1022,1027],{"type":45,"value":1014},"Projectional reality changes what to test: invalid syntax usually cannot be entered, so parser-style tests are nearly irrelevant. Test the ",{"type":39,"tag":54,"props":1016,"children":1017},{},[1018],{"type":45,"value":1019},"semantic seams",{"type":45,"value":1021}," — visible vs. invisible scope targets, host\u002Fguest type bridges, generator contracts (placeholder IDs, abstract signatures, priorities), and migration of representative example models. Run the model checker over the example suite after every structural or generator change. Full per-kind checklist: ",{"type":39,"tag":157,"props":1023,"children":1025},{"className":1024},[],[1026],{"type":45,"value":923},{"type":45,"value":99},{"type":39,"tag":242,"props":1029,"children":1030},{},[1031],{"type":39,"tag":48,"props":1032,"children":1033},{},[1034,1036,1041,1043,1048,1050,1056],{"type":45,"value":1035},"Code snippets here are ",{"type":39,"tag":54,"props":1037,"children":1038},{},[1039],{"type":45,"value":1040},"illustrative pseudo-syntax",{"type":45,"value":1042}," showing the ",{"type":39,"tag":62,"props":1044,"children":1045},{},[1046],{"type":45,"value":1047},"shape",{"type":45,"value":1049}," of each pattern — implement the real artifacts through MPS MCP tools and the linked aspect skills; never hand-edit ",{"type":39,"tag":157,"props":1051,"children":1053},{"className":1052},[],[1054],{"type":45,"value":1055},".mps",{"type":45,"value":1057}," files.",{"items":1059,"total":1184},[1060,1073,1082,1091,1102,1112,1124,1133,1142,1152,1161,1174],{"slug":836,"name":836,"fn":1061,"description":1062,"org":1063,"tags":1064,"stars":19,"repoUrl":20,"updatedAt":1072},"configure JetBrains MPS module dependencies","Wire MPS module and model dependencies, used languages, used devkits, extended languages, runtime solutions, accessory models, and language\u002Fdependency versions. Use when adding\u002Fremoving module dependencies, importing languages or devkits into a model, declaring runtime solutions, or shipping accessory content visible to consumers without explicit import.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1065,1066,1069],{"name":13,"slug":14,"type":15},{"name":1067,"slug":1068,"type":15},"Configuration","configuration",{"name":1070,"slug":1071,"type":15},"Engineering","engineering","2026-07-17T06:06:57.311661",{"slug":1074,"name":1074,"fn":1075,"description":1076,"org":1077,"tags":1078,"stars":19,"repoUrl":20,"updatedAt":1081},"mps-aspect-actions","define and edit MPS node factories","Use when defining or editing MPS node factories (the \"actions\" aspect) — `NodeFactories` roots, per-concept `NodeFactory` setup functions that initialize a freshly created node and optionally copy data from a replaced `sampleNode`, plus the actions aspect's `CopyPasteHandlers` and `PasteWrappers` roots. Reach for this skill when a substitution, side transform, completion replacement, or `add new initialized(...)` should preserve fields from the node it is replacing, or when defaults set in a constructor are not enough.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1079,1080],{"name":13,"slug":14,"type":15},{"name":1070,"slug":1071,"type":15},"2026-07-17T06:04:48.066901",{"slug":1083,"name":1083,"fn":1084,"description":1085,"org":1086,"tags":1087,"stars":19,"repoUrl":20,"updatedAt":1090},"mps-aspect-behavior","define and edit MPS concept behavior","Use when defining or editing MPS `ConceptBehavior` — per-concept methods (non-virtual \u002F virtual \u002F abstract \u002F static \u002F virtual static), constructors, virtual dispatch (MRO), super and interface-default calls (`super\u003CInterface>.method`), overriding methods from `lang.core.behavior` interfaces such as `ScopeProvider.getScope` \u002F `INamedConcept.getName` \u002F `BaseConcept.getPresentation`, calling sibling methods (`LocalBehaviorMethodCall`) and behavior methods from other aspects via `node.method(...)`. Reach for this skill whenever the task involves authoring or modifying `\u003Clang>\u002FlanguageModels\u002Fbehavior.mps`.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1088,1089],{"name":13,"slug":14,"type":15},{"name":1070,"slug":1071,"type":15},"2026-07-13T06:45:21.757084",{"slug":1092,"name":1092,"fn":1093,"description":1094,"org":1095,"tags":1096,"stars":19,"repoUrl":20,"updatedAt":1101},"mps-aspect-constraints","define JetBrains MPS language constraints","Use when defining or editing MPS language constraints — property validators \u002F setters \u002F getters, referent search scopes (imperative or inherited via `ScopeProvider.getScope`), `referentSetHandler` side effects, default-scope blocks, `canBeChild` \u002F `canBeParent` \u002F `canBeAncestor` \u002F `canBeRoot` placement rules, `defaultConcreteConcept` for abstract concepts, `set \u003Cread-only>` and `{name}` aliasing, and scope helpers (`SimpleRoleScope`, `ListScope`, `CompositeScope`, `HidingByNameScope`). Reach for this skill whenever the task involves authoring or modifying `\u003Clang>\u002FlanguageModels\u002Fconstraints.mps`.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1097,1098],{"name":13,"slug":14,"type":15},{"name":1099,"slug":1100,"type":15},"Code Analysis","code-analysis","2026-07-23T05:41:33.639365",{"slug":1103,"name":1103,"fn":1104,"description":1105,"org":1106,"tags":1107,"stars":19,"repoUrl":20,"updatedAt":1111},"mps-aspect-dataflow","define and debug MPS dataflow builders","Use when defining or debugging MPS dataflow builders for a concept — control\u002Fdata flow declarations that drive reachability analysis and variable-use checking. Covers DataFlowBuilderDeclaration, BuilderBlock, emit instructions (code for, jump, ifjump, label, read, write, ret, mayBeUnreachable), positions (AfterPosition, BeforePosition, LabelPosition), the jetbrains.mps.lang.dataFlow language, the NodeParameter implicit, BL+smodel usage inside builder bodies, and IBuilderMode for advanced analyses such as nullable\u002Fnon-null tracking.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1108],{"name":1109,"slug":1110,"type":15},"Data Analysis","data-analysis","2026-07-13T06:45:19.114674",{"slug":1113,"name":1113,"fn":1114,"description":1115,"org":1116,"tags":1117,"stars":19,"repoUrl":20,"updatedAt":1123},"mps-aspect-editor","define MPS editor layouts","Use when creating or changing MPS editor definitions — the overall workflow from scaffolding a `ConceptEditorDeclaration` through componentizing reusable `EditorComponentDeclaration`s, refining cell models and cell layouts, applying style sheets and indent-layout style items, wiring smart references, leveraging inheritance via super-concepts and interfaces, inspecting (`print_node_json`, `show_node_representation`) and validating (`check_root_node_problems`). Covers `jetbrains.mps.lang.editor` cell models (`CellModel_RefNode`\u002F`CellModel_RefNodeList`\u002F`CellModel_RefCell`\u002F`CellModel_Property`\u002F`CellModel_Constant`), layout choices, and JSON blueprints for common editor shapes. For the non-layout side (action maps, keymaps, transformation\u002Fsubstitute menus) use `mps-aspect-editor-menus-and-keymaps`.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1118,1120],{"name":1119,"slug":153,"type":15},"Design",{"name":1121,"slug":1122,"type":15},"UI Components","ui-components","2026-07-23T05:41:56.638151",{"slug":1125,"name":1125,"fn":1126,"description":1127,"org":1128,"tags":1129,"stars":19,"repoUrl":20,"updatedAt":1132},"mps-aspect-editor-menus-and-keymaps","author MPS editor menus and keymaps","Use when authoring the **non-layout** parts of the MPS editor aspect — what happens when the user types, presses a key, triggers completion, pastes, or invokes a context action. Covers action maps (`CellActionMapDeclaration`), cell keymaps (`CellKeyMapDeclaration`), transformation menus (`TransformationMenu_Default` \u002F `_Named` \u002F `_Contribution`), substitute menus (`SubstituteMenu_Default` \u002F `SubstituteMenu` \u002F contributions), side transforms (LEFT\u002FRIGHT), legacy cell menus, paste wrappers and copy-paste handlers (in the actions language), completion styling, reference presentation, two-step deletion, and the editor selection API. Trigger terms: `actionMap`, `keyMap`, `delete_action_id`, `transformationMenu`, `substituteMenu`, `Ctrl+Space`, `Ctrl+Alt+B`, side transform, paste wrapper, completion styling, `PasteWrappers`, `CopyPasteHandlers`. For the **layout** side (cells, layouts, style sheets) use `mps-aspect-editor` instead.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1130,1131],{"name":1070,"slug":1071,"type":15},{"name":1121,"slug":1122,"type":15},"2026-07-23T05:41:49.666535",{"slug":1134,"name":1134,"fn":1135,"description":1136,"org":1137,"tags":1138,"stars":19,"repoUrl":20,"updatedAt":1141},"mps-aspect-generation-plan","modify MPS generation plans","Use when defining or modifying an MPS generation plan — explicit ordering of generators, checkpoints for cross-model reference resolution, forks for parallel branches, IncludePlan composition, conditional PlanContribution activation, ParameterEquals\u002FConceptListSelector fork selectors, and InitModelAttributes for targetFacet routing. Apply when working with @genplan models, the jetbrains.mps.lang.generator.plan language, attaching plans via DevKits or the Custom generation facet, or debugging cross-model mapping label resolution.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1139,1140],{"name":13,"slug":14,"type":15},{"name":1070,"slug":1071,"type":15},"2026-07-13T06:44:59.507855",{"slug":1143,"name":1143,"fn":1144,"description":1145,"org":1146,"tags":1147,"stars":19,"repoUrl":20,"updatedAt":1151},"mps-aspect-generator","define JetBrains MPS generator rules","Use when defining or modifying MPS generators — author a generator module, add or edit root\u002Freduction\u002Fweaving\u002Fpattern mapping rules, attach template macros ($COPY_SRC, $LOOP, $IF, $PROPERTY, $REF, $SWITCH, $MAP_SRC, $WEAVE, $INSERT, $LABEL, $TRACE, $VAR), wire mapping labels, build template switches, write pre\u002Fpost mapping scripts, navigate `genContext`, or debug \"rule didn't fire\", missing references, empty output, infinite reduction loops, and generated-Java compile failures.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1148,1149,1150],{"name":13,"slug":14,"type":15},{"name":1099,"slug":1100,"type":15},{"name":1070,"slug":1071,"type":15},"2026-07-17T06:06:58.042999",{"slug":1153,"name":1153,"fn":1154,"description":1155,"org":1156,"tags":1157,"stars":19,"repoUrl":20,"updatedAt":1160},"mps-aspect-intentions","define and edit MPS intentions","Use when defining or editing MPS intentions (the Alt+Enter context-action aspect) — adding `IntentionDeclaration` roots, parameterized or surround-with variants, description\u002FisApplicable\u002Fexecute blocks, child-filter functions, factory-initialized AST splicing, or debugging why an intention is not offered. Lives in the language's `intentions` model and uses `jetbrains.mps.lang.intentions`.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1158,1159],{"name":13,"slug":14,"type":15},{"name":1070,"slug":1071,"type":15},"2026-07-23T05:41:48.692899",{"slug":1162,"name":1162,"fn":1163,"description":1164,"org":1165,"tags":1166,"stars":19,"repoUrl":20,"updatedAt":1173},"mps-aspect-migrations","author and debug MPS migration scripts","Use when authoring or debugging MPS migration scripts that upgrade user models after a language definition changes — covers jetbrains.mps.lang.migration (MigrationScript class-based, PureMigrationScript declarative, MoveConcept\u002FMoveContainmentLink\u002FMoveReferenceLink\u002FMoveProperty, ordering via OrderDependency, data exchange via putData\u002FgetData, RefactoringLog, ConceptMigrationReference) and jetbrains.mps.lang.script Enhancement Scripts (MigrationScript with MigrationScriptPart_Instance, ExtractInterfaceMigration, FactoryMigrationScriptPart, CommentMigrationScriptPart) — when a model needs version-gated upgrade, concept rename or removal, link or property rename, instance-level transformation, or composition of migration steps.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1167,1170],{"name":1168,"slug":1169,"type":15},"Debugging","debugging",{"name":1171,"slug":1172,"type":15},"Migration","migration","2026-07-13T06:45:20.372122",{"slug":1175,"name":1175,"fn":1176,"description":1177,"org":1178,"tags":1179,"stars":19,"repoUrl":20,"updatedAt":1183},"mps-aspect-structure-concepts","define concepts in MPS structure aspect","Define concepts, interface concepts, enumerations, and constrained data types in an MPS language's `structure` aspect. Covers smart-reference detection, alias rules, cardinality, INamedConcept usage, bulk creation, and the full `mps_mcp_alter_structure` \u002F `mps_mcp_query_structure` reference. Use when authoring or modifying a language's structure model.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1180],{"name":1181,"slug":1182,"type":15},"Data Modeling","data-modeling","2026-07-23T05:41:30.705975",188,{"items":1186,"total":1222},[1187,1193,1198,1203,1208,1212,1217],{"slug":836,"name":836,"fn":1061,"description":1062,"org":1188,"tags":1189,"stars":19,"repoUrl":20,"updatedAt":1072},{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1190,1191,1192],{"name":13,"slug":14,"type":15},{"name":1067,"slug":1068,"type":15},{"name":1070,"slug":1071,"type":15},{"slug":1074,"name":1074,"fn":1075,"description":1076,"org":1194,"tags":1195,"stars":19,"repoUrl":20,"updatedAt":1081},{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1196,1197],{"name":13,"slug":14,"type":15},{"name":1070,"slug":1071,"type":15},{"slug":1083,"name":1083,"fn":1084,"description":1085,"org":1199,"tags":1200,"stars":19,"repoUrl":20,"updatedAt":1090},{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1201,1202],{"name":13,"slug":14,"type":15},{"name":1070,"slug":1071,"type":15},{"slug":1092,"name":1092,"fn":1093,"description":1094,"org":1204,"tags":1205,"stars":19,"repoUrl":20,"updatedAt":1101},{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1206,1207],{"name":13,"slug":14,"type":15},{"name":1099,"slug":1100,"type":15},{"slug":1103,"name":1103,"fn":1104,"description":1105,"org":1209,"tags":1210,"stars":19,"repoUrl":20,"updatedAt":1111},{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1211],{"name":1109,"slug":1110,"type":15},{"slug":1113,"name":1113,"fn":1114,"description":1115,"org":1213,"tags":1214,"stars":19,"repoUrl":20,"updatedAt":1123},{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1215,1216],{"name":1119,"slug":153,"type":15},{"name":1121,"slug":1122,"type":15},{"slug":1125,"name":1125,"fn":1126,"description":1127,"org":1218,"tags":1219,"stars":19,"repoUrl":20,"updatedAt":1132},{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1220,1221],{"name":1070,"slug":1071,"type":15},{"name":1121,"slug":1122,"type":15},31]