[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill-jetbrains-reviewing-changes":3,"mdc-69mx2y-key":32,"related-repo-jetbrains-reviewing-changes":345,"related-org-jetbrains-reviewing-changes":384},{"slug":4,"name":4,"fn":5,"description":6,"org":7,"tags":11,"stars":22,"repoUrl":23,"updatedAt":24,"license":25,"forks":26,"topics":27,"repo":28,"sourceUrl":30,"mdContent":31},"reviewing-changes","review agent-written code changes","Use when a review package asks you to review a plan step's change set (todo.startReview): you are the REVIEWER, not the author. How to judge an agent-written diff, file findings with add_review_comment, and settle with exactly one review_verdict.",{"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],{"name":13,"slug":14,"type":15},"Code Review","code-review","tag",{"name":17,"slug":18,"type":15},"Engineering","engineering",{"name":20,"slug":21,"type":15},"Code Analysis","code-analysis",7,"https:\u002F\u002Fgithub.com\u002FJetBrains\u002Fthinkrail","2026-08-28T15:08:39.670058",null,0,[],{"repoUrl":23,"stars":22,"forks":26,"topics":29,"description":25},[],"https:\u002F\u002Fgithub.com\u002FJetBrains\u002Fthinkrail\u002Ftree\u002FHEAD\u002Fpackages\u002Fpi-todos\u002Fskills\u002Freviewing-changes","---\nname: reviewing-changes\ndescription: \"Use when a review package asks you to review a plan step's change set (todo.startReview): you are the REVIEWER, not the author. How to judge an agent-written diff, file findings with add_review_comment, and settle with exactly one review_verdict.\"\n---\n\n# Reviewing a plan step's changes\n\nYou review code another agent wrote. Generated code fails differently from human code: it *looks* more\ncorrect than it is. Review the diff against the step's intent and evidence — never against \"does it look\nplausible\".\n\n## Order of review (where agent code actually fails)\n\n1. **Intent match first.** Re-read the step title\u002Fnote. The signature failure is a correct solution to a\n   *slightly different* problem. Does the diff do what the step asked — all of it, and only it?\n2. **Scope drift.** List the changed files before reading bodies. Anything beyond the step's ask\n   (drive-by refactors, renames, new dependencies) that the summary did not disclose is a finding. Also\n   scan every changed file for content that doesn't belong at all — a pasted URL\u002Ftoken\u002Fcredential,\n   leftover debug logging, commented-out code — it hides easily inside a file that's legitimately in\n   scope, since nothing about the file itself looks wrong.\n3. **Verify the verification claim.** Never trust \"tests pass\" — run the named check yourself when\n   cheap (`bun test \u003Cdir>`, `typecheck`). **CI gaming is a top failure**: weakened\u002Fskipped\u002Fdeleted\n   tests, `|| true`, broadened lint ignores, `@ts-expect-error`\u002F`as any` — each is a finding even when\n   the code is right.\n4. **Reality of every API.** Hallucinated or wrong-signature imports\u002Fcalls are common: check that each\n   new import exists and matches the lockfile\u002Fdocs, not the author's claim.\n5. **Correctness at the edges.** Error paths, empty\u002FNone cases, concurrency, resource cleanup — agents\n   under-test edges they didn't hit.\n6. **Hunt what is MISSING, not just what is wrong.** The worst bugs in agent code are omissions — no\n   added line is wrong, a needed line is absent, so reading the diff top-to-bottom finds nothing. For\n   every piece of state the change introduces or touches (in-memory map\u002Flatch\u002Fregistration\u002Fmark, temp\n   resource, persisted flag), trace its full lifecycle in the resulting code: where it is set → where\n   it is cleared → what clears it on EVERY exit path (success, error, abort, a later unrelated turn).\n   A set without a clear on some path is a finding. For every fire-and-forget or detached call, name\n   what rolls back when it rejects. Then check the OTHER side: for every READER of that same state, ask\n   what it does when the state is absent or stale. A permissive default at the read site (an optional\n   spread, `?? fallback`, silently continuing instead of rejecting) is a finding exactly like a missing\n   clear — a clean producer-side lifecycle still lets a consumer misbehave on the gap.\n7. **Invariant audit.** Collect the explicit guarantees in the owning module's SPEC.md (and its\n   parent) that touch the changed seams, then check each changed code path against each guarantee —\n   mechanically, path × guarantee (spec_grep the area). A diff that contradicts a recorded decision\n   or silently drops a stated guarantee is a finding even if it works. The reverse gap is a finding\n   too: a diff that establishes or changes an invariant without updating the owning SPEC.md to state\n   it — the next review reads a spec that no longer describes reality.\n8. **Parallel surfaces and external defaults.** When two paths produce the same artifact (primary +\n   fallback, manual + automated, UI + wire), diff their inputs — one deriving from state the other\n   ignores is a finding. For every external command\u002FAPI call, name the defaults the code silently\n   relies on (target branch, cwd, locale, config lookup) and verify each is the intended one. When a\n   config documents a state (\"unset ⇒ default\"), verify the UI\u002Fwire can actually reach it — a\n   documented state with no transition into it is a finding.\n9. Style is NOT your job unless it hides a bug.\n\n## Filing findings\n\n- One concrete problem = one `add_review_comment` (exact path + lines): what is wrong, why it matters,\n  and what to do instead. Cite evidence (a failing command, the spec line) — never vibes.\n- Every finding states a concrete **failure scenario** — the sequence of events in which a user or the\n  system actually hits the bug. A problem you can't put a scenario to isn't a finding yet (this also\n  kills nitpicks).\n- Severity in the first word: `BUG:`, `RISK:`, `DEBT:`. Skip nitpicks a formatter would catch.\n- On a RE-review, start from the named delta but widen from there: when the fix touches shared state\n  (a map\u002Flatch\u002Fregistration\u002Flifecycle rule), check every OTHER reader\u002Fwriter of that state too, not\n  just the line the original finding cited — a fix that patches only the named call site while a\n  sibling call site on the same invariant stays broken is not addressed. `resolve_comment` only the\n  earlier findings the fix actually closes; unresolved ones stand.\n- A fix with no test reproducing the failure scenario it closes is itself a finding — nothing else\n  stops the same regression next time an unrelated change touches the same lifecycle.\n\n## The verdict\n\nExactly one `review_verdict` per package, after the work above — never before:\n- `approve` — no findings that block; note may name accepted debt.\n- `request_changes` — your comments must be addressed; the note is one line naming the biggest one.\nApproving without having read the diff, or requesting changes without a filed comment, are both failures.\n",{"data":33,"body":34},{"name":4,"description":6},{"type":35,"children":36},"root",[37,46,60,67,221,227,301,307,320],{"type":38,"tag":39,"props":40,"children":42},"element","h1",{"id":41},"reviewing-a-plan-steps-changes",[43],{"type":44,"value":45},"text","Reviewing a plan step's changes",{"type":38,"tag":47,"props":48,"children":49},"p",{},[50,52,58],{"type":44,"value":51},"You review code another agent wrote. Generated code fails differently from human code: it ",{"type":38,"tag":53,"props":54,"children":55},"em",{},[56],{"type":44,"value":57},"looks",{"type":44,"value":59}," more\ncorrect than it is. Review the diff against the step's intent and evidence — never against \"does it look\nplausible\".",{"type":38,"tag":61,"props":62,"children":64},"h2",{"id":63},"order-of-review-where-agent-code-actually-fails",[65],{"type":44,"value":66},"Order of review (where agent code actually fails)",{"type":38,"tag":68,"props":69,"children":70},"ol",{},[71,90,100,158,168,178,196,206,216],{"type":38,"tag":72,"props":73,"children":74},"li",{},[75,81,83,88],{"type":38,"tag":76,"props":77,"children":78},"strong",{},[79],{"type":44,"value":80},"Intent match first.",{"type":44,"value":82}," Re-read the step title\u002Fnote. The signature failure is a correct solution to a\n",{"type":38,"tag":53,"props":84,"children":85},{},[86],{"type":44,"value":87},"slightly different",{"type":44,"value":89}," problem. Does the diff do what the step asked — all of it, and only it?",{"type":38,"tag":72,"props":91,"children":92},{},[93,98],{"type":38,"tag":76,"props":94,"children":95},{},[96],{"type":44,"value":97},"Scope drift.",{"type":44,"value":99}," List the changed files before reading bodies. Anything beyond the step's ask\n(drive-by refactors, renames, new dependencies) that the summary did not disclose is a finding. Also\nscan every changed file for content that doesn't belong at all — a pasted URL\u002Ftoken\u002Fcredential,\nleftover debug logging, commented-out code — it hides easily inside a file that's legitimately in\nscope, since nothing about the file itself looks wrong.",{"type":38,"tag":72,"props":101,"children":102},{},[103,108,110,117,119,125,127,132,134,140,142,148,150,156],{"type":38,"tag":76,"props":104,"children":105},{},[106],{"type":44,"value":107},"Verify the verification claim.",{"type":44,"value":109}," Never trust \"tests pass\" — run the named check yourself when\ncheap (",{"type":38,"tag":111,"props":112,"children":114},"code",{"className":113},[],[115],{"type":44,"value":116},"bun test \u003Cdir>",{"type":44,"value":118},", ",{"type":38,"tag":111,"props":120,"children":122},{"className":121},[],[123],{"type":44,"value":124},"typecheck",{"type":44,"value":126},"). ",{"type":38,"tag":76,"props":128,"children":129},{},[130],{"type":44,"value":131},"CI gaming is a top failure",{"type":44,"value":133},": weakened\u002Fskipped\u002Fdeleted\ntests, ",{"type":38,"tag":111,"props":135,"children":137},{"className":136},[],[138],{"type":44,"value":139},"|| true",{"type":44,"value":141},", broadened lint ignores, ",{"type":38,"tag":111,"props":143,"children":145},{"className":144},[],[146],{"type":44,"value":147},"@ts-expect-error",{"type":44,"value":149},"\u002F",{"type":38,"tag":111,"props":151,"children":153},{"className":152},[],[154],{"type":44,"value":155},"as any",{"type":44,"value":157}," — each is a finding even when\nthe code is right.",{"type":38,"tag":72,"props":159,"children":160},{},[161,166],{"type":38,"tag":76,"props":162,"children":163},{},[164],{"type":44,"value":165},"Reality of every API.",{"type":44,"value":167}," Hallucinated or wrong-signature imports\u002Fcalls are common: check that each\nnew import exists and matches the lockfile\u002Fdocs, not the author's claim.",{"type":38,"tag":72,"props":169,"children":170},{},[171,176],{"type":38,"tag":76,"props":172,"children":173},{},[174],{"type":44,"value":175},"Correctness at the edges.",{"type":44,"value":177}," Error paths, empty\u002FNone cases, concurrency, resource cleanup — agents\nunder-test edges they didn't hit.",{"type":38,"tag":72,"props":179,"children":180},{},[181,186,188,194],{"type":38,"tag":76,"props":182,"children":183},{},[184],{"type":44,"value":185},"Hunt what is MISSING, not just what is wrong.",{"type":44,"value":187}," The worst bugs in agent code are omissions — no\nadded line is wrong, a needed line is absent, so reading the diff top-to-bottom finds nothing. For\nevery piece of state the change introduces or touches (in-memory map\u002Flatch\u002Fregistration\u002Fmark, temp\nresource, persisted flag), trace its full lifecycle in the resulting code: where it is set → where\nit is cleared → what clears it on EVERY exit path (success, error, abort, a later unrelated turn).\nA set without a clear on some path is a finding. For every fire-and-forget or detached call, name\nwhat rolls back when it rejects. Then check the OTHER side: for every READER of that same state, ask\nwhat it does when the state is absent or stale. A permissive default at the read site (an optional\nspread, ",{"type":38,"tag":111,"props":189,"children":191},{"className":190},[],[192],{"type":44,"value":193},"?? fallback",{"type":44,"value":195},", silently continuing instead of rejecting) is a finding exactly like a missing\nclear — a clean producer-side lifecycle still lets a consumer misbehave on the gap.",{"type":38,"tag":72,"props":197,"children":198},{},[199,204],{"type":38,"tag":76,"props":200,"children":201},{},[202],{"type":44,"value":203},"Invariant audit.",{"type":44,"value":205}," Collect the explicit guarantees in the owning module's SPEC.md (and its\nparent) that touch the changed seams, then check each changed code path against each guarantee —\nmechanically, path × guarantee (spec_grep the area). A diff that contradicts a recorded decision\nor silently drops a stated guarantee is a finding even if it works. The reverse gap is a finding\ntoo: a diff that establishes or changes an invariant without updating the owning SPEC.md to state\nit — the next review reads a spec that no longer describes reality.",{"type":38,"tag":72,"props":207,"children":208},{},[209,214],{"type":38,"tag":76,"props":210,"children":211},{},[212],{"type":44,"value":213},"Parallel surfaces and external defaults.",{"type":44,"value":215}," When two paths produce the same artifact (primary +\nfallback, manual + automated, UI + wire), diff their inputs — one deriving from state the other\nignores is a finding. For every external command\u002FAPI call, name the defaults the code silently\nrelies on (target branch, cwd, locale, config lookup) and verify each is the intended one. When a\nconfig documents a state (\"unset ⇒ default\"), verify the UI\u002Fwire can actually reach it — a\ndocumented state with no transition into it is a finding.",{"type":38,"tag":72,"props":217,"children":218},{},[219],{"type":44,"value":220},"Style is NOT your job unless it hides a bug.",{"type":38,"tag":61,"props":222,"children":224},{"id":223},"filing-findings",[225],{"type":44,"value":226},"Filing findings",{"type":38,"tag":228,"props":229,"children":230},"ul",{},[231,244,256,283,296],{"type":38,"tag":72,"props":232,"children":233},{},[234,236,242],{"type":44,"value":235},"One concrete problem = one ",{"type":38,"tag":111,"props":237,"children":239},{"className":238},[],[240],{"type":44,"value":241},"add_review_comment",{"type":44,"value":243}," (exact path + lines): what is wrong, why it matters,\nand what to do instead. Cite evidence (a failing command, the spec line) — never vibes.",{"type":38,"tag":72,"props":245,"children":246},{},[247,249,254],{"type":44,"value":248},"Every finding states a concrete ",{"type":38,"tag":76,"props":250,"children":251},{},[252],{"type":44,"value":253},"failure scenario",{"type":44,"value":255}," — the sequence of events in which a user or the\nsystem actually hits the bug. A problem you can't put a scenario to isn't a finding yet (this also\nkills nitpicks).",{"type":38,"tag":72,"props":257,"children":258},{},[259,261,267,268,274,275,281],{"type":44,"value":260},"Severity in the first word: ",{"type":38,"tag":111,"props":262,"children":264},{"className":263},[],[265],{"type":44,"value":266},"BUG:",{"type":44,"value":118},{"type":38,"tag":111,"props":269,"children":271},{"className":270},[],[272],{"type":44,"value":273},"RISK:",{"type":44,"value":118},{"type":38,"tag":111,"props":276,"children":278},{"className":277},[],[279],{"type":44,"value":280},"DEBT:",{"type":44,"value":282},". Skip nitpicks a formatter would catch.",{"type":38,"tag":72,"props":284,"children":285},{},[286,288,294],{"type":44,"value":287},"On a RE-review, start from the named delta but widen from there: when the fix touches shared state\n(a map\u002Flatch\u002Fregistration\u002Flifecycle rule), check every OTHER reader\u002Fwriter of that state too, not\njust the line the original finding cited — a fix that patches only the named call site while a\nsibling call site on the same invariant stays broken is not addressed. ",{"type":38,"tag":111,"props":289,"children":291},{"className":290},[],[292],{"type":44,"value":293},"resolve_comment",{"type":44,"value":295}," only the\nearlier findings the fix actually closes; unresolved ones stand.",{"type":38,"tag":72,"props":297,"children":298},{},[299],{"type":44,"value":300},"A fix with no test reproducing the failure scenario it closes is itself a finding — nothing else\nstops the same regression next time an unrelated change touches the same lifecycle.",{"type":38,"tag":61,"props":302,"children":304},{"id":303},"the-verdict",[305],{"type":44,"value":306},"The verdict",{"type":38,"tag":47,"props":308,"children":309},{},[310,312,318],{"type":44,"value":311},"Exactly one ",{"type":38,"tag":111,"props":313,"children":315},{"className":314},[],[316],{"type":44,"value":317},"review_verdict",{"type":44,"value":319}," per package, after the work above — never before:",{"type":38,"tag":228,"props":321,"children":322},{},[323,334],{"type":38,"tag":72,"props":324,"children":325},{},[326,332],{"type":38,"tag":111,"props":327,"children":329},{"className":328},[],[330],{"type":44,"value":331},"approve",{"type":44,"value":333}," — no findings that block; note may name accepted debt.",{"type":38,"tag":72,"props":335,"children":336},{},[337,343],{"type":38,"tag":111,"props":338,"children":340},{"className":339},[],[341],{"type":44,"value":342},"request_changes",{"type":44,"value":344}," — your comments must be addressed; the note is one line naming the biggest one.\nApproving without having read the diff, or requesting changes without a filed comment, are both failures.",{"items":346,"total":383},[347,361,367],{"slug":348,"name":348,"fn":349,"description":350,"org":351,"tags":352,"stars":22,"repoUrl":23,"updatedAt":360},"reflecting-findings","verify agent review findings","Use when a reflection package hands you another agent's review findings to verify (before they become a fix request): you are the REFLECTOR, an independent skeptic. Judge each finding against the real code and settle it with reflect_finding — kept or refuted.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[353,354,357],{"name":20,"slug":21,"type":15},{"name":355,"slug":356,"type":15},"Debugging","debugging",{"name":358,"slug":359,"type":15},"QA","qa","2026-08-28T15:09:33.670824",{"slug":4,"name":4,"fn":5,"description":6,"org":362,"tags":363,"stars":22,"repoUrl":23,"updatedAt":24},{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[364,365,366],{"name":20,"slug":21,"type":15},{"name":13,"slug":14,"type":15},{"name":17,"slug":18,"type":15},{"slug":368,"name":368,"fn":369,"description":370,"org":371,"tags":372,"stars":22,"repoUrl":23,"updatedAt":382},"todos","manage shared live task lists","This chat has a shared, live TODO plan — your tasks for the conversation, which the user also edits. Read this skill and reach for the todo_* tools whenever a request takes more than a couple of steps. It covers the plan model (group = task, items = its steps; loose items are the user's lane), how to work it: propose the plan FIRST (todo_write before you ask questions or start work), work tasks strictly in order with one step in_progress, keep statuses current, re-read the list (source of truth) to catch the user's edits, respect removals, and never delete done items.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[373,376,379],{"name":374,"slug":375,"type":15},"Collaboration","collaboration",{"name":377,"slug":378,"type":15},"Productivity","productivity",{"name":380,"slug":381,"type":15},"Task Management","task-management","2026-08-28T14:35:23.64911",3,{"items":385,"total":510},[386,402,411,420,429,439,452,461,470,480,489,500],{"slug":387,"name":387,"fn":388,"description":389,"org":390,"tags":391,"stars":399,"repoUrl":400,"updatedAt":401},"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},[392,395,398],{"name":393,"slug":394,"type":15},"Architecture","architecture",{"name":396,"slug":397,"type":15},"Configuration","configuration",{"name":17,"slug":18,"type":15},1650,"https:\u002F\u002Fgithub.com\u002FJetBrains\u002FMPS","2026-07-17T06:06:57.311661",{"slug":403,"name":403,"fn":404,"description":405,"org":406,"tags":407,"stars":399,"repoUrl":400,"updatedAt":410},"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},[408,409],{"name":393,"slug":394,"type":15},{"name":17,"slug":18,"type":15},"2026-07-17T06:04:48.066901",{"slug":412,"name":412,"fn":413,"description":414,"org":415,"tags":416,"stars":399,"repoUrl":400,"updatedAt":419},"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},[417,418],{"name":393,"slug":394,"type":15},{"name":17,"slug":18,"type":15},"2026-07-13T06:45:21.757084",{"slug":421,"name":421,"fn":422,"description":423,"org":424,"tags":425,"stars":399,"repoUrl":400,"updatedAt":428},"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},[426,427],{"name":393,"slug":394,"type":15},{"name":20,"slug":21,"type":15},"2026-07-23T05:41:33.639365",{"slug":430,"name":430,"fn":431,"description":432,"org":433,"tags":434,"stars":399,"repoUrl":400,"updatedAt":438},"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},[435],{"name":436,"slug":437,"type":15},"Data Analysis","data-analysis","2026-07-13T06:45:19.114674",{"slug":440,"name":440,"fn":441,"description":442,"org":443,"tags":444,"stars":399,"repoUrl":400,"updatedAt":451},"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},[445,448],{"name":446,"slug":447,"type":15},"Design","design",{"name":449,"slug":450,"type":15},"UI Components","ui-components","2026-07-23T05:41:56.638151",{"slug":453,"name":453,"fn":454,"description":455,"org":456,"tags":457,"stars":399,"repoUrl":400,"updatedAt":460},"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},[458,459],{"name":17,"slug":18,"type":15},{"name":449,"slug":450,"type":15},"2026-07-23T05:41:49.666535",{"slug":462,"name":462,"fn":463,"description":464,"org":465,"tags":466,"stars":399,"repoUrl":400,"updatedAt":469},"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},[467,468],{"name":393,"slug":394,"type":15},{"name":17,"slug":18,"type":15},"2026-07-13T06:44:59.507855",{"slug":471,"name":471,"fn":472,"description":473,"org":474,"tags":475,"stars":399,"repoUrl":400,"updatedAt":479},"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},[476,477,478],{"name":393,"slug":394,"type":15},{"name":20,"slug":21,"type":15},{"name":17,"slug":18,"type":15},"2026-07-17T06:06:58.042999",{"slug":481,"name":481,"fn":482,"description":483,"org":484,"tags":485,"stars":399,"repoUrl":400,"updatedAt":488},"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},[486,487],{"name":393,"slug":394,"type":15},{"name":17,"slug":18,"type":15},"2026-07-23T05:41:48.692899",{"slug":490,"name":490,"fn":491,"description":492,"org":493,"tags":494,"stars":399,"repoUrl":400,"updatedAt":499},"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},[495,496],{"name":355,"slug":356,"type":15},{"name":497,"slug":498,"type":15},"Migration","migration","2026-07-13T06:45:20.372122",{"slug":501,"name":501,"fn":502,"description":503,"org":504,"tags":505,"stars":399,"repoUrl":400,"updatedAt":509},"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},[506],{"name":507,"slug":508,"type":15},"Data Modeling","data-modeling","2026-07-23T05:41:30.705975",190]