[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill-jetbrains-domain-decomposition-api-design-advisor":3,"mdc-b1ujhg-key":36,"related-org-jetbrains-domain-decomposition-api-design-advisor":516,"related-repo-jetbrains-domain-decomposition-api-design-advisor":645},{"slug":4,"name":4,"fn":5,"description":6,"org":7,"tags":11,"stars":25,"repoUrl":26,"updatedAt":27,"license":28,"forks":29,"topics":30,"repo":31,"sourceUrl":34,"mdContent":35},"domain-decomposition-api-design-advisor","decompose business scope into bounded contexts","Decompose business scope into bounded contexts, module or service boundaries, workflows, and API contracts before implementation begins. Use when shaping a new feature, service, or major redesign; when requirements are underspecified; when consistency, idempotency, and integration boundaries must be made explicit; or when ADR-quality tradeoff reasoning is needed for Kotlin plus Spring systems.",{"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,19,22],{"name":13,"slug":14,"type":15},"Architecture","architecture","tag",{"name":17,"slug":18,"type":15},"System Design","system-design",{"name":20,"slug":21,"type":15},"Engineering","engineering",{"name":23,"slug":24,"type":15},"API Development","api-development",252,"https:\u002F\u002Fgithub.com\u002FJetBrains\u002Fskills","2026-07-13T06:43:19.501386",null,17,[],{"repoUrl":26,"stars":25,"forks":29,"topics":32,"description":33},[],"Curated agent skills collection verified by JetBrains","https:\u002F\u002Fgithub.com\u002FJetBrains\u002Fskills\u002Ftree\u002FHEAD\u002Fdomain-decomposition-api-design-advisor","---\nname: domain-decomposition-api-design-advisor\ndescription: Decompose business scope into bounded contexts, module or service boundaries, workflows, and API contracts before implementation begins. Use when shaping a new feature, service, or major redesign; when requirements are underspecified; when consistency, idempotency, and integration boundaries must be made explicit; or when ADR-quality tradeoff reasoning is needed for Kotlin plus Spring systems.\nmetadata:\n  short-description: \"Decompose scope before code exists\"\n  author: Kotlin\n  source: https:\u002F\u002Fgithub.com\u002FKotlin\u002Fkotlin-backend-agent-skills\u002Ftree\u002Fmain\u002F.agents\u002Fskills\u002Fdomain-decomposition-api-design-advisor\n---\n\n# Domain Decomposition API Design Advisor\n\nSource mapping: Tier 3 specialized skill derived from `Kotlin_Spring_Developer_Pipeline.md` (`SK-25`).\n\n## Mission\n\nConvert vague product intent into explicit technical boundaries and contracts that can survive implementation and change.\nOptimize for clear ownership, explicit invariants, and low coupling rather than premature microservice enthusiasm.\n\n## Inputs To Gather\n\n- Business goals, user journeys, and success criteria.\n- Known constraints: SLA, throughput, latency, audit, privacy, compliance, data retention.\n- Existing system boundaries, shared data, and integration points.\n- Failure and retry expectations, especially around money, inventory, identity, and messaging.\n- Team topology and deployment constraints when they influence boundary choices.\n\n## Decomposition Workflow\n\n1. Break the feature into use cases and state transitions.\n2. Identify the core nouns, aggregates, and decision points.\n3. Identify where consistency must be strong and where eventual consistency is acceptable.\n4. Separate commands from queries when that improves clarity, not by default.\n5. Identify external actors and dependencies.\n6. Decide whether the right boundary is:\n   - package\n   - module\n   - bounded context inside a modular monolith\n   - separate service\n7. Design API and event contracts only after the domain boundary is clear.\n\n## Boundary Rules\n\n- Prefer a module boundary over a service boundary when independent deployment, ownership, or scaling pressure is weak.\n- Shared database tables across service boundaries are usually a warning sign, not a convenience.\n- Draw boundaries around invariants and ownership, not around CRUD screens.\n- Distinguish reference data sharing from operational write ownership.\n- A boundary is only real if dependency direction, data ownership, and failure handling agree.\n\n## API Design Rules\n\n- Start from consumer use cases, not only internal data shape.\n- Make idempotency, concurrency, versioning, and error semantics explicit.\n- Choose synchronous request-response only when latency, consistency, and dependency reliability make it appropriate.\n- Prefer additive evolution and stable machine-readable codes.\n- Decide whether the API is public, partner-facing, internal synchronous, or asynchronous event-driven. Each has different compatibility expectations.\n\n## Kotlin And Modeling Nuances\n\n- Use sealed hierarchies for genuinely closed state machines or domain outcomes.\n- Use value classes for domain primitives when they improve clarity and the stack can support them.\n- Keep DTOs as transport shapes; do not let them become the entire domain model.\n- Use nullability to express meaning, not missing analysis.\n\n## Advanced Architecture Traps\n\n- \"Microservice by default\" often creates distributed transactions, duplicated auth, and fractured observability before it creates value.\n- A modular monolith with strong boundaries may be a better target state than several chatty services.\n- Event-driven decomposition without clear ownership and replay semantics creates ambiguity, not decoupling.\n- If a feature needs read-your-write guarantees, an eventually consistent split may impose hidden UX or support costs.\n- Public APIs and internal orchestration APIs should not necessarily look the same.\n- ADRs that record only the chosen option are weak. Capture rejected alternatives and why they lost.\n\n## Advanced Boundary Nuances\n\n- Reporting boundaries and transactional boundaries are often different. Do not let analytics-driven query convenience dictate write ownership.\n- Anti-corruption layers are often cheaper than pretending two bounded contexts share the same ubiquitous language.\n- Team ownership, deployment cadence, and support rotation are architecture inputs when boundaries are long-lived. Ignore them only if the code will remain single-team.\n- Multi-tenant behavior, data residency, and audit obligations can force a boundary that pure domain language does not reveal immediately.\n- Event choreography without a clear owner for recovery and replay becomes shared confusion. If no one owns correction, the boundary is weak.\n- Some features deserve process-manager or saga modeling, but only when the business truly spans separate consistency boundaries.\n\n## Expert Heuristics\n\n- If two modules change together for every feature, they probably are not separate bounded contexts yet.\n- Prefer boundaries that reduce the number of concepts a team must hold in working memory during a single change.\n- If an API contract must survive multiple client generations, design for behavioral compatibility, not only field-level compatibility.\n- Write the failure story for each boundary. If the team cannot explain how retries, compensation, and partial success work, the design is not finished.\n\n## Output Contract\n\nReturn these sections:\n\n- `Problem framing`: the use cases, constraints, and unknowns.\n- `Proposed boundaries`: module or service decomposition and ownership.\n- `Consistency map`: where transactions, idempotency, and eventual consistency apply.\n- `API or event contracts`: the principal commands, queries, and error semantics.\n- `Tradeoffs`: why this boundary shape is better than the main alternatives.\n- `ADR outline`: decision, options, rationale, and follow-up risks.\n\n## Guardrails\n\n- Do not propose microservices where a disciplined module boundary is sufficient.\n- Do not ignore non-functional requirements just because the feature narrative sounds simple.\n- Do not mistake CRUD decomposition for domain decomposition.\n- Do not design APIs before clarifying ownership and invariants.\n\n## Quality Bar\n\nA good run of this skill gives the team a boundary model that survives implementation pressure and future change.\nA bad run produces a plausible architecture diagram with no ownership, no consistency story, and no contract discipline.\n",{"data":37,"body":42},{"name":4,"description":6,"metadata":38},{"short-description":39,"author":40,"source":41},"Decompose scope before code exists","Kotlin","https:\u002F\u002Fgithub.com\u002FKotlin\u002Fkotlin-backend-agent-skills\u002Ftree\u002Fmain\u002F.agents\u002Fskills\u002Fdomain-decomposition-api-design-advisor",{"type":43,"children":44},"root",[45,53,76,83,88,94,124,130,192,198,226,232,260,266,289,295,328,334,367,373,396,402,407,476,482,505,511],{"type":46,"tag":47,"props":48,"children":49},"element","h1",{"id":4},[50],{"type":51,"value":52},"text","Domain Decomposition API Design Advisor",{"type":46,"tag":54,"props":55,"children":56},"p",{},[57,59,66,68,74],{"type":51,"value":58},"Source mapping: Tier 3 specialized skill derived from ",{"type":46,"tag":60,"props":61,"children":63},"code",{"className":62},[],[64],{"type":51,"value":65},"Kotlin_Spring_Developer_Pipeline.md",{"type":51,"value":67}," (",{"type":46,"tag":60,"props":69,"children":71},{"className":70},[],[72],{"type":51,"value":73},"SK-25",{"type":51,"value":75},").",{"type":46,"tag":77,"props":78,"children":80},"h2",{"id":79},"mission",[81],{"type":51,"value":82},"Mission",{"type":46,"tag":54,"props":84,"children":85},{},[86],{"type":51,"value":87},"Convert vague product intent into explicit technical boundaries and contracts that can survive implementation and change.\nOptimize for clear ownership, explicit invariants, and low coupling rather than premature microservice enthusiasm.",{"type":46,"tag":77,"props":89,"children":91},{"id":90},"inputs-to-gather",[92],{"type":51,"value":93},"Inputs To Gather",{"type":46,"tag":95,"props":96,"children":97},"ul",{},[98,104,109,114,119],{"type":46,"tag":99,"props":100,"children":101},"li",{},[102],{"type":51,"value":103},"Business goals, user journeys, and success criteria.",{"type":46,"tag":99,"props":105,"children":106},{},[107],{"type":51,"value":108},"Known constraints: SLA, throughput, latency, audit, privacy, compliance, data retention.",{"type":46,"tag":99,"props":110,"children":111},{},[112],{"type":51,"value":113},"Existing system boundaries, shared data, and integration points.",{"type":46,"tag":99,"props":115,"children":116},{},[117],{"type":51,"value":118},"Failure and retry expectations, especially around money, inventory, identity, and messaging.",{"type":46,"tag":99,"props":120,"children":121},{},[122],{"type":51,"value":123},"Team topology and deployment constraints when they influence boundary choices.",{"type":46,"tag":77,"props":125,"children":127},{"id":126},"decomposition-workflow",[128],{"type":51,"value":129},"Decomposition Workflow",{"type":46,"tag":131,"props":132,"children":133},"ol",{},[134,139,144,149,154,159,187],{"type":46,"tag":99,"props":135,"children":136},{},[137],{"type":51,"value":138},"Break the feature into use cases and state transitions.",{"type":46,"tag":99,"props":140,"children":141},{},[142],{"type":51,"value":143},"Identify the core nouns, aggregates, and decision points.",{"type":46,"tag":99,"props":145,"children":146},{},[147],{"type":51,"value":148},"Identify where consistency must be strong and where eventual consistency is acceptable.",{"type":46,"tag":99,"props":150,"children":151},{},[152],{"type":51,"value":153},"Separate commands from queries when that improves clarity, not by default.",{"type":46,"tag":99,"props":155,"children":156},{},[157],{"type":51,"value":158},"Identify external actors and dependencies.",{"type":46,"tag":99,"props":160,"children":161},{},[162,164],{"type":51,"value":163},"Decide whether the right boundary is:\n",{"type":46,"tag":95,"props":165,"children":166},{},[167,172,177,182],{"type":46,"tag":99,"props":168,"children":169},{},[170],{"type":51,"value":171},"package",{"type":46,"tag":99,"props":173,"children":174},{},[175],{"type":51,"value":176},"module",{"type":46,"tag":99,"props":178,"children":179},{},[180],{"type":51,"value":181},"bounded context inside a modular monolith",{"type":46,"tag":99,"props":183,"children":184},{},[185],{"type":51,"value":186},"separate service",{"type":46,"tag":99,"props":188,"children":189},{},[190],{"type":51,"value":191},"Design API and event contracts only after the domain boundary is clear.",{"type":46,"tag":77,"props":193,"children":195},{"id":194},"boundary-rules",[196],{"type":51,"value":197},"Boundary Rules",{"type":46,"tag":95,"props":199,"children":200},{},[201,206,211,216,221],{"type":46,"tag":99,"props":202,"children":203},{},[204],{"type":51,"value":205},"Prefer a module boundary over a service boundary when independent deployment, ownership, or scaling pressure is weak.",{"type":46,"tag":99,"props":207,"children":208},{},[209],{"type":51,"value":210},"Shared database tables across service boundaries are usually a warning sign, not a convenience.",{"type":46,"tag":99,"props":212,"children":213},{},[214],{"type":51,"value":215},"Draw boundaries around invariants and ownership, not around CRUD screens.",{"type":46,"tag":99,"props":217,"children":218},{},[219],{"type":51,"value":220},"Distinguish reference data sharing from operational write ownership.",{"type":46,"tag":99,"props":222,"children":223},{},[224],{"type":51,"value":225},"A boundary is only real if dependency direction, data ownership, and failure handling agree.",{"type":46,"tag":77,"props":227,"children":229},{"id":228},"api-design-rules",[230],{"type":51,"value":231},"API Design Rules",{"type":46,"tag":95,"props":233,"children":234},{},[235,240,245,250,255],{"type":46,"tag":99,"props":236,"children":237},{},[238],{"type":51,"value":239},"Start from consumer use cases, not only internal data shape.",{"type":46,"tag":99,"props":241,"children":242},{},[243],{"type":51,"value":244},"Make idempotency, concurrency, versioning, and error semantics explicit.",{"type":46,"tag":99,"props":246,"children":247},{},[248],{"type":51,"value":249},"Choose synchronous request-response only when latency, consistency, and dependency reliability make it appropriate.",{"type":46,"tag":99,"props":251,"children":252},{},[253],{"type":51,"value":254},"Prefer additive evolution and stable machine-readable codes.",{"type":46,"tag":99,"props":256,"children":257},{},[258],{"type":51,"value":259},"Decide whether the API is public, partner-facing, internal synchronous, or asynchronous event-driven. Each has different compatibility expectations.",{"type":46,"tag":77,"props":261,"children":263},{"id":262},"kotlin-and-modeling-nuances",[264],{"type":51,"value":265},"Kotlin And Modeling Nuances",{"type":46,"tag":95,"props":267,"children":268},{},[269,274,279,284],{"type":46,"tag":99,"props":270,"children":271},{},[272],{"type":51,"value":273},"Use sealed hierarchies for genuinely closed state machines or domain outcomes.",{"type":46,"tag":99,"props":275,"children":276},{},[277],{"type":51,"value":278},"Use value classes for domain primitives when they improve clarity and the stack can support them.",{"type":46,"tag":99,"props":280,"children":281},{},[282],{"type":51,"value":283},"Keep DTOs as transport shapes; do not let them become the entire domain model.",{"type":46,"tag":99,"props":285,"children":286},{},[287],{"type":51,"value":288},"Use nullability to express meaning, not missing analysis.",{"type":46,"tag":77,"props":290,"children":292},{"id":291},"advanced-architecture-traps",[293],{"type":51,"value":294},"Advanced Architecture Traps",{"type":46,"tag":95,"props":296,"children":297},{},[298,303,308,313,318,323],{"type":46,"tag":99,"props":299,"children":300},{},[301],{"type":51,"value":302},"\"Microservice by default\" often creates distributed transactions, duplicated auth, and fractured observability before it creates value.",{"type":46,"tag":99,"props":304,"children":305},{},[306],{"type":51,"value":307},"A modular monolith with strong boundaries may be a better target state than several chatty services.",{"type":46,"tag":99,"props":309,"children":310},{},[311],{"type":51,"value":312},"Event-driven decomposition without clear ownership and replay semantics creates ambiguity, not decoupling.",{"type":46,"tag":99,"props":314,"children":315},{},[316],{"type":51,"value":317},"If a feature needs read-your-write guarantees, an eventually consistent split may impose hidden UX or support costs.",{"type":46,"tag":99,"props":319,"children":320},{},[321],{"type":51,"value":322},"Public APIs and internal orchestration APIs should not necessarily look the same.",{"type":46,"tag":99,"props":324,"children":325},{},[326],{"type":51,"value":327},"ADRs that record only the chosen option are weak. Capture rejected alternatives and why they lost.",{"type":46,"tag":77,"props":329,"children":331},{"id":330},"advanced-boundary-nuances",[332],{"type":51,"value":333},"Advanced Boundary Nuances",{"type":46,"tag":95,"props":335,"children":336},{},[337,342,347,352,357,362],{"type":46,"tag":99,"props":338,"children":339},{},[340],{"type":51,"value":341},"Reporting boundaries and transactional boundaries are often different. Do not let analytics-driven query convenience dictate write ownership.",{"type":46,"tag":99,"props":343,"children":344},{},[345],{"type":51,"value":346},"Anti-corruption layers are often cheaper than pretending two bounded contexts share the same ubiquitous language.",{"type":46,"tag":99,"props":348,"children":349},{},[350],{"type":51,"value":351},"Team ownership, deployment cadence, and support rotation are architecture inputs when boundaries are long-lived. Ignore them only if the code will remain single-team.",{"type":46,"tag":99,"props":353,"children":354},{},[355],{"type":51,"value":356},"Multi-tenant behavior, data residency, and audit obligations can force a boundary that pure domain language does not reveal immediately.",{"type":46,"tag":99,"props":358,"children":359},{},[360],{"type":51,"value":361},"Event choreography without a clear owner for recovery and replay becomes shared confusion. If no one owns correction, the boundary is weak.",{"type":46,"tag":99,"props":363,"children":364},{},[365],{"type":51,"value":366},"Some features deserve process-manager or saga modeling, but only when the business truly spans separate consistency boundaries.",{"type":46,"tag":77,"props":368,"children":370},{"id":369},"expert-heuristics",[371],{"type":51,"value":372},"Expert Heuristics",{"type":46,"tag":95,"props":374,"children":375},{},[376,381,386,391],{"type":46,"tag":99,"props":377,"children":378},{},[379],{"type":51,"value":380},"If two modules change together for every feature, they probably are not separate bounded contexts yet.",{"type":46,"tag":99,"props":382,"children":383},{},[384],{"type":51,"value":385},"Prefer boundaries that reduce the number of concepts a team must hold in working memory during a single change.",{"type":46,"tag":99,"props":387,"children":388},{},[389],{"type":51,"value":390},"If an API contract must survive multiple client generations, design for behavioral compatibility, not only field-level compatibility.",{"type":46,"tag":99,"props":392,"children":393},{},[394],{"type":51,"value":395},"Write the failure story for each boundary. If the team cannot explain how retries, compensation, and partial success work, the design is not finished.",{"type":46,"tag":77,"props":397,"children":399},{"id":398},"output-contract",[400],{"type":51,"value":401},"Output Contract",{"type":46,"tag":54,"props":403,"children":404},{},[405],{"type":51,"value":406},"Return these sections:",{"type":46,"tag":95,"props":408,"children":409},{},[410,421,432,443,454,465],{"type":46,"tag":99,"props":411,"children":412},{},[413,419],{"type":46,"tag":60,"props":414,"children":416},{"className":415},[],[417],{"type":51,"value":418},"Problem framing",{"type":51,"value":420},": the use cases, constraints, and unknowns.",{"type":46,"tag":99,"props":422,"children":423},{},[424,430],{"type":46,"tag":60,"props":425,"children":427},{"className":426},[],[428],{"type":51,"value":429},"Proposed boundaries",{"type":51,"value":431},": module or service decomposition and ownership.",{"type":46,"tag":99,"props":433,"children":434},{},[435,441],{"type":46,"tag":60,"props":436,"children":438},{"className":437},[],[439],{"type":51,"value":440},"Consistency map",{"type":51,"value":442},": where transactions, idempotency, and eventual consistency apply.",{"type":46,"tag":99,"props":444,"children":445},{},[446,452],{"type":46,"tag":60,"props":447,"children":449},{"className":448},[],[450],{"type":51,"value":451},"API or event contracts",{"type":51,"value":453},": the principal commands, queries, and error semantics.",{"type":46,"tag":99,"props":455,"children":456},{},[457,463],{"type":46,"tag":60,"props":458,"children":460},{"className":459},[],[461],{"type":51,"value":462},"Tradeoffs",{"type":51,"value":464},": why this boundary shape is better than the main alternatives.",{"type":46,"tag":99,"props":466,"children":467},{},[468,474],{"type":46,"tag":60,"props":469,"children":471},{"className":470},[],[472],{"type":51,"value":473},"ADR outline",{"type":51,"value":475},": decision, options, rationale, and follow-up risks.",{"type":46,"tag":77,"props":477,"children":479},{"id":478},"guardrails",[480],{"type":51,"value":481},"Guardrails",{"type":46,"tag":95,"props":483,"children":484},{},[485,490,495,500],{"type":46,"tag":99,"props":486,"children":487},{},[488],{"type":51,"value":489},"Do not propose microservices where a disciplined module boundary is sufficient.",{"type":46,"tag":99,"props":491,"children":492},{},[493],{"type":51,"value":494},"Do not ignore non-functional requirements just because the feature narrative sounds simple.",{"type":46,"tag":99,"props":496,"children":497},{},[498],{"type":51,"value":499},"Do not mistake CRUD decomposition for domain decomposition.",{"type":46,"tag":99,"props":501,"children":502},{},[503],{"type":51,"value":504},"Do not design APIs before clarifying ownership and invariants.",{"type":46,"tag":77,"props":506,"children":508},{"id":507},"quality-bar",[509],{"type":51,"value":510},"Quality Bar",{"type":46,"tag":54,"props":512,"children":513},{},[514],{"type":51,"value":515},"A good run of this skill gives the team a boundary model that survives implementation pressure and future change.\nA bad run produces a plausible architecture diagram with no ownership, no consistency story, and no contract discipline.",{"items":517,"total":644},[518,532,541,550,561,571,584,593,602,612,621,634],{"slug":519,"name":519,"fn":520,"description":521,"org":522,"tags":523,"stars":529,"repoUrl":530,"updatedAt":531},"mps-aspect-accessories","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},[524,525,528],{"name":13,"slug":14,"type":15},{"name":526,"slug":527,"type":15},"Configuration","configuration",{"name":20,"slug":21,"type":15},1650,"https:\u002F\u002Fgithub.com\u002FJetBrains\u002FMPS","2026-07-17T06:06:57.311661",{"slug":533,"name":533,"fn":534,"description":535,"org":536,"tags":537,"stars":529,"repoUrl":530,"updatedAt":540},"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},[538,539],{"name":13,"slug":14,"type":15},{"name":20,"slug":21,"type":15},"2026-07-17T06:04:48.066901",{"slug":542,"name":542,"fn":543,"description":544,"org":545,"tags":546,"stars":529,"repoUrl":530,"updatedAt":549},"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},[547,548],{"name":13,"slug":14,"type":15},{"name":20,"slug":21,"type":15},"2026-07-13T06:45:21.757084",{"slug":551,"name":551,"fn":552,"description":553,"org":554,"tags":555,"stars":529,"repoUrl":530,"updatedAt":560},"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},[556,557],{"name":13,"slug":14,"type":15},{"name":558,"slug":559,"type":15},"Code Analysis","code-analysis","2026-07-23T05:41:33.639365",{"slug":562,"name":562,"fn":563,"description":564,"org":565,"tags":566,"stars":529,"repoUrl":530,"updatedAt":570},"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},[567],{"name":568,"slug":569,"type":15},"Data Analysis","data-analysis","2026-07-13T06:45:19.114674",{"slug":572,"name":572,"fn":573,"description":574,"org":575,"tags":576,"stars":529,"repoUrl":530,"updatedAt":583},"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},[577,580],{"name":578,"slug":579,"type":15},"Design","design",{"name":581,"slug":582,"type":15},"UI Components","ui-components","2026-07-23T05:41:56.638151",{"slug":585,"name":585,"fn":586,"description":587,"org":588,"tags":589,"stars":529,"repoUrl":530,"updatedAt":592},"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},[590,591],{"name":20,"slug":21,"type":15},{"name":581,"slug":582,"type":15},"2026-07-23T05:41:49.666535",{"slug":594,"name":594,"fn":595,"description":596,"org":597,"tags":598,"stars":529,"repoUrl":530,"updatedAt":601},"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},[599,600],{"name":13,"slug":14,"type":15},{"name":20,"slug":21,"type":15},"2026-07-13T06:44:59.507855",{"slug":603,"name":603,"fn":604,"description":605,"org":606,"tags":607,"stars":529,"repoUrl":530,"updatedAt":611},"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},[608,609,610],{"name":13,"slug":14,"type":15},{"name":558,"slug":559,"type":15},{"name":20,"slug":21,"type":15},"2026-07-17T06:06:58.042999",{"slug":613,"name":613,"fn":614,"description":615,"org":616,"tags":617,"stars":529,"repoUrl":530,"updatedAt":620},"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},[618,619],{"name":13,"slug":14,"type":15},{"name":20,"slug":21,"type":15},"2026-07-23T05:41:48.692899",{"slug":622,"name":622,"fn":623,"description":624,"org":625,"tags":626,"stars":529,"repoUrl":530,"updatedAt":633},"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},[627,630],{"name":628,"slug":629,"type":15},"Debugging","debugging",{"name":631,"slug":632,"type":15},"Migration","migration","2026-07-13T06:45:20.372122",{"slug":635,"name":635,"fn":636,"description":637,"org":638,"tags":639,"stars":529,"repoUrl":530,"updatedAt":643},"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},[640],{"name":641,"slug":642,"type":15},"Data Modeling","data-modeling","2026-07-23T05:41:30.705975",188,{"items":646,"total":763},[647,666,681,695,710,732,749],{"slug":648,"name":648,"fn":649,"description":650,"org":651,"tags":652,"stars":25,"repoUrl":26,"updatedAt":665},"algorithmic-art","create generative art with p5.js","Creating algorithmic art using p5.js with seeded randomness and interactive parameter exploration. Use this when users request creating art using code, generative art, algorithmic art, flow fields, or particle systems. Create original algorithmic art rather than copying existing artists' work to avoid copyright violations.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[653,656,659,662],{"name":654,"slug":655,"type":15},"Creative","creative",{"name":657,"slug":658,"type":15},"Generative Art","generative-art",{"name":660,"slug":661,"type":15},"Graphics","graphics",{"name":663,"slug":664,"type":15},"JavaScript","javascript","2026-07-13T06:41:35.540127",{"slug":667,"name":667,"fn":668,"description":669,"org":670,"tags":671,"stars":25,"repoUrl":26,"updatedAt":680},"antfu","configure JavaScript projects with Anthony Fu's tools","Anthony Fu's opinionated tooling and conventions for JavaScript\u002FTypeScript projects. Use when setting up new projects, configuring ESLint\u002FPrettier alternatives, monorepos, library publishing, or when the user mentions Anthony Fu's preferences.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[672,675,676,677],{"name":673,"slug":674,"type":15},"Best Practices","best-practices",{"name":20,"slug":21,"type":15},{"name":663,"slug":664,"type":15},{"name":678,"slug":679,"type":15},"TypeScript","typescript","2026-07-13T06:43:13.153309",{"slug":682,"name":682,"fn":683,"description":684,"org":685,"tags":686,"stars":25,"repoUrl":26,"updatedAt":694},"brand-guidelines","apply Anthropic brand guidelines","Applies Anthropic's official brand colors and typography to any sort of artifact that may benefit from having Anthropic's look-and-feel. Use it when brand colors or style guidelines, visual formatting, or company design standards apply.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[687,690,691],{"name":688,"slug":689,"type":15},"Branding","branding",{"name":578,"slug":579,"type":15},{"name":692,"slug":693,"type":15},"Typography","typography","2026-07-13T06:43:06.077629",{"slug":696,"name":696,"fn":697,"description":698,"org":699,"tags":700,"stars":25,"repoUrl":26,"updatedAt":709},"canvas-design","create visual art and design assets","Create beautiful visual art in .png and .pdf documents using design philosophy. You should use this skill when the user asks to create a poster, piece of art, design, or other static piece. Create original visual designs, never copying existing artists' work to avoid copyright violations.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[701,702,703,706],{"name":654,"slug":655,"type":15},{"name":578,"slug":579,"type":15},{"name":704,"slug":705,"type":15},"Images","images",{"name":707,"slug":708,"type":15},"PDF","pdf","2026-07-13T06:39:58.803113",{"slug":711,"name":711,"fn":712,"description":713,"org":714,"tags":715,"stars":25,"repoUrl":26,"updatedAt":731},"ci-cd-containerization-advisor","design CI\u002FCD pipelines for Kotlin applications","Design reproducible build, image, and deployment pipelines for Kotlin plus Spring applications, including CI verification, layered containers, rollout safety, and deployment-time migration coordination. Use when creating or improving Dockerfiles, CI workflows, image hardening, Kubernetes manifests, release gates, or deployment strategies for Spring Boot services, especially where build reproducibility and operational safety matter.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[716,719,722,725,726,728],{"name":717,"slug":718,"type":15},"CI\u002FCD","ci-cd",{"name":720,"slug":721,"type":15},"Containers","containers",{"name":723,"slug":724,"type":15},"Deployment","deployment",{"name":20,"slug":21,"type":15},{"name":40,"slug":727,"type":15},"kotlin",{"name":729,"slug":730,"type":15},"Spring","spring","2026-07-13T06:41:47.83899",{"slug":733,"name":733,"fn":734,"description":735,"org":736,"tags":737,"stars":25,"repoUrl":26,"updatedAt":748},"cloudflare-deploy","deploy applications to Cloudflare","Deploy applications and infrastructure to Cloudflare using Workers, Pages, and related platform services. Use when the user asks to deploy, host, publish, or set up a project on Cloudflare.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[738,741,744,747],{"name":739,"slug":740,"type":15},"Cloudflare","cloudflare",{"name":742,"slug":743,"type":15},"Cloudflare Pages","cloudflare-pages",{"name":745,"slug":746,"type":15},"Cloudflare Workers","cloudflare-workers",{"name":723,"slug":724,"type":15},"2026-07-17T06:04:42.853896",{"slug":750,"name":750,"fn":751,"description":752,"org":753,"tags":754,"stars":25,"repoUrl":26,"updatedAt":762},"compose-ui-control","interact with Compose Desktop applications","Control a running Compose Desktop application via HTTP. Use when you need to interact with UI elements, click buttons, enter text, wait for elements to appear, or capture screenshots in a Compose Desktop app that has compose-ui-test-server enabled.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[755,758,761],{"name":756,"slug":757,"type":15},"Automation","automation",{"name":759,"slug":760,"type":15},"Desktop","desktop",{"name":581,"slug":582,"type":15},"2026-07-13T06:40:38.798626",128]