{"owner":"microsoft","repo":"language-server-protocol","hasSkills":true,"totalSkillsCount":2,"totalTokensCount":2678,"categories":["anthropic-skill"],"hasMcp":false,"mcpConfig":null,"found":[".github/skills/lsp-node-protocol-consistency/references/consistency-checklist.md",".github/skills/lsp-node-protocol-consistency/SKILL.md"],"skills":{".github/skills/lsp-node-protocol-consistency/references/consistency-checklist.md":"# Consistency checklist\n\nUse this reference after identifying the feature or types in scope.\n\n## Surface map\n\n| Concern | Specification repository | Node repository |\n| --- | --- | --- |\n| Current version | `_data/specifications.yml` | `protocol/package.json` and meta-model metadata |\n| Feature prose and snippets | `_specifications/lsp/<version>/<area>/<feature>.md` | Relevant files below |\n| Shared wire data | Feature or `types/*.md` pages | `types/src/main.ts` |\n| Request or notification | Feature page | `protocol/src/common/protocol.<feature>.ts` or `protocol.ts` |\n| Capabilities | Feature page and `general/initialize.md` | `ClientCapabilities` and `ServerCapabilities` in protocol sources |\n| Public protocol exports | TypeScript snippets imply public names | `protocol/src/common/protocol.ts` and `api.ts` |\n| Client integration | Normative client behavior | `client/src/common/`, converters, middleware, and tests |\n| Server integration | Normative server behavior | `server/src/common/` and tests |\n| Machine-readable contract | `metaModel/metaModel.json` | Generated `protocol/metaModel.json` |\n| Meta-model types | `metaModel/metaModel.ts` | `tools/src/metaModel.ts` |\n| Meta-model schema | `metaModel/metaModel.schema.json` | Generated `protocol/metaModel.schema.json` |\n| Navigation and release notes | Version TOC and change log | Usually not applicable |\n\nThe Node meta-model generator reads the protocol TypeScript program, including\ntypes imported from `@vscode/languageserver-types`. A missing generated entry\ncan therefore originate in either `types/src/main.ts`, protocol declarations,\nexports, or generator-recognition conventions.\n\n## Request and notification checks\n\n- Exact method string, including `$`, slashes, and casing.\n- Correct direction.\n- Request versus notification.\n- Parameter type and whether parameters may be omitted.\n- Result type, including `null`, arrays, and unions.\n- Partial-result and work-done-progress types.\n- Error-data type when protocol-specific.\n- Registration-options type.\n- Client capability path.\n- Server capability path.\n- Static registration identifier support.\n- Dynamic registration support.\n- Cancellation and retrigger behavior stated in prose.\n\n## Type checks\n\n- Public type name and link target.\n- Structure inheritance or intersection members.\n- Every property name and documentation.\n- Required versus optional.\n- Nullable versus non-nullable.\n- Primitive kind, especially `integer`, `uinteger`, and `decimal`.\n- Array element type and map key/value types.\n- Union alternatives and literal values.\n- Enum representation and exact numeric or string values.\n- Recursive references and aliases.\n- Serialization shape; helper factories and guards must not change it.\n- `@since`, `@deprecated`, and `@proposed` metadata.\n\nType aliases and interfaces can be equivalent. Compare their resulting wire\nshapes rather than requiring the same TypeScript syntax. Conversely, do not\ntreat `property?: T` as equivalent to `property: T | null`.\n\n## Capability and registration checks\n\n- Client capability is nested under the documented path.\n- Server capability uses the documented property and value type.\n- Boolean shorthand is supported only when the specification permits it.\n- Registration options include the documented selector and static ID mixins.\n- The message descriptor uses the same registration-options type.\n- Client code advertises and consumes the capability consistently.\n- Server APIs expose handlers only for valid directions.\n\n## Stability and version checks\n\n- New stable additions carry the intended `@since <major>.<minor>.<patch>`.\n- Proposed declarations remain marked proposed on both sides.\n- Finalizing a proposal removes proposal markers and moves/exports declarations\n  according to established Node conventions.\n- Deprecation text names the replacement when one exists.\n- Patch-level corrections do not accidentally claim a new minor version.\n- Previous specification versions stay unchanged unless the task explicitly\n  corrects historical documentation.\n- Package version bumps are release work and are not implied by a contract\n  consistency fix.\n\n## Runtime integration checks\n\nApply these only when the Node client or server implements the feature:\n\n- Public feature registration and initialization.\n- Protocol-to-editor and editor-to-protocol conversion.\n- Middleware or handler signatures.\n- Cancellation-token propagation.\n- Partial-result and progress handling.\n- Dynamic registration and unregistration.\n- Capability negotiation and fallback behavior.\n- Node and browser entry-point exposure where applicable.\n- Focused tests for serialization, conversion, registration, and handlers.\n\n## Completion gate\n\nConsistency is established only when:\n\n1. the normative prose and snippets describe the intended behavior;\n2. Node wire declarations encode the same contract;\n3. applicable client/server behavior honors it;\n4. generated Node meta-model artifacts are current;\n5. specification meta-model mirrors match semantically;\n6. affected builds, lints, and tests pass;\n7. no unexplained divergence remains in either repository.\n",".github/skills/lsp-node-protocol-consistency/SKILL.md":"---\nname: lsp-node-protocol-consistency\ndescription: Keeps the Language Server Protocol specification and the vscode-languageserver-node TypeScript implementation aligned. Use when adding, changing, reviewing, or auditing LSP requests, notifications, capabilities, registration options, wire types, proposed or final status, since tags, meta-model data, or related documentation across microsoft/language-server-protocol and microsoft/vscode-languageserver-node.\nlicense: MIT\ncompatibility: Requires local checkouts of microsoft/language-server-protocol and microsoft/vscode-languageserver-node, plus Node.js, npm, and git. Ruby and Bundler are optional for building the specification site.\nmetadata:\n  author: microsoft\n  version: \"1.0\"\n---\n\n# LSP Node and specification consistency\n\nMaintain one coherent LSP wire contract across the normative specification and\nthe Node implementation. Do not equate textual similarity with compatibility:\nTypeScript aliases, interfaces, intersections, helper namespaces, and factories\ncan differ while describing the same wire shape.\n\n## Establish the scope\n\n1. Locate both repository roots instead of assuming fixed directory names:\n   - The specification root contains `_data/specifications.yml`.\n   - The Node root contains `protocol/package.json`, `types/src/main.ts`, and\n     `tools/src/metaModel.ts`.\n2. Read `git status --short --branch` in both repositories before editing.\n   Preserve unrelated changes. If task files already have conflicting edits,\n   ask how to proceed.\n3. Read `_data/specifications.yml` to identify the current LSP version unless\n   the user named a version. Do not update previous versions unless the task is\n   explicitly a historical correction.\n4. Determine whether the task is:\n   - an audit or review,\n   - a specification-first protocol change,\n   - an implementation correction, or\n   - synchronization of an already agreed contract.\n5. Identify the exact methods, capability paths, types, properties, enum\n   values, and documentation affected. Search both repositories for all of\n   them before changing files.\n\nIf the intended wire behavior is ambiguous or the repositories disagree in a\nway the task does not resolve, stop and ask which behavior is intended.\n\n## Apply source-of-truth rules\n\n- The specification prose defines normative protocol behavior.\n- However the implementation is the point of truth of the actual behavior. The\n  protocol should follow the implementation if not noted otherwise.\n- The Node TypeScript sources define the Node API and generate the meta model.\n- The specification's `metaModel.json`, `metaModel.ts`, and\n  `metaModel.schema.json` are mirrors of artifacts from the Node repository.\n- Never resolve a disagreement by blindly copying one side. Establish the\n  intended contract, update the authoritative source for each concern, and\n  then synchronize derived artifacts.\n\nRead [the consistency checklist](references/consistency-checklist.md) for the\nsurface map and the invariants that must be checked.\n\n## Build a contract matrix\n\nFor every affected request, notification, or type, record and compare:\n\n- method string and message direction;\n- parameter, result, error data, partial result, and registration types;\n- client and server capability paths;\n- static and dynamic registration behavior;\n- property names, optionality, nullability, arrays, maps, unions, and literals;\n- numeric or string enum values;\n- `@since`, deprecation, and proposed/final status;\n- behavioral requirements stated only in prose;\n- public exports and, where applicable, client/server feature wiring.\n\nTreat these distinctions as wire-significant:\n\n- omitted versus present with `null`;\n- optional versus required;\n- integer versus decimal;\n- an array versus a single value;\n- a literal value versus a general primitive;\n- client-to-server versus server-to-client versus both;\n- static capability advertisement versus dynamic registration.\n\n## Make coordinated changes\n\nWhen the task calls for edits, use an analogous completed feature as a pattern\nand update every applicable surface.\n\n### Specification repository\n\nUpdate the current version under `_specifications/lsp/<version>/`:\n\n- the feature or shared-type Markdown;\n- `specification.md` when a new topic must be included;\n- `_data/specification-<major>-<minor>-toc.yml` when navigation changes;\n- versioned message includes when the change affects shared messages;\n- the change log when the protocol version gains a user-visible feature.\n\nKeep prose examples and TypeScript snippets semantically aligned. Preserve\nanchors and links when moving or renaming content.\n\n### Node repository\n\nUpdate only the layers required by the change:\n\n- `types/src/main.ts` for serializable LSP data types and their public helpers;\n- `protocol/src/common/protocol.ts` for shared protocol types, capabilities,\n  imports, and exports;\n- `protocol/src/common/protocol.<feature>.ts` for feature-specific messages;\n- `protocol/src/common/api.ts` for public API exposure when needed;\n- `client/src/common/` for client capability, registration, conversion, and\n  middleware support;\n- `server/src/common/` for typed server handlers and feature exposure;\n- focused unit or integration tests for changed runtime behavior.\n\nNot every wire change requires client or server feature code. Explain why a\nlayer is not applicable rather than adding empty plumbing.\n\n## Regenerate and synchronize the meta model\n\nAfter changing Node protocol or type sources:\n\n1. Compile the affected Node workspaces.\n2. From the Node `protocol` workspace, run `npm run compile:metaModelTool`.\n3. From the Node repository root, run:\n   - `npm run generate:metaModel`\n   - `npm run generate:metaModelSchema`\n4. Inspect the generated diff. Unexpected additions, omissions, reordered\n   declarations, or lost documentation usually indicate an implementation or\n   generator-modeling error; fix the source instead of hand-editing generated\n   JSON.\n5. Copy the intended generated artifacts to the current specification:\n   - `protocol/metaModel.json` to\n     `_specifications/lsp/<version>/metaModel/metaModel.json`;\n   - `tools/src/metaModel.ts` to\n     `_specifications/lsp/<version>/metaModel/metaModel.ts`;\n   - `protocol/metaModel.schema.json` to\n     `_specifications/lsp/<version>/metaModel/metaModel.schema.json`.\n6. Run the bundled comparison from the specification root:\n\n   `node .github/skills/lsp-node-protocol-consistency/scripts/compare-meta-model.mjs --node-repo <node-repository-root>`\n\nThe comparison is read-only. It compares JSON semantically so irrelevant\nobject-key ordering does not create false failures, while array ordering and\nall values remain significant.\n\nMeta-model equality is necessary but not sufficient. It does not prove that\nnormative prose, examples, client/server behavior, or runtime helpers agree.\n\n## Validate\n\nUse the smallest existing commands that cover the changed layers, escalating\nonly when needed:\n\n- Node type changes: `npm run compile:types`, then the `types` lint and tests.\n- Protocol changes: `npm run compile:protocol`, then the `protocol` lint and\n  Node tests.\n- Server changes: compile, lint, and test the `server` workspace.\n- Client changes: compile and lint `client`; run the focused\n  `client-node-tests` integration tests that exercise the feature.\n- Specification Markdown, includes, or navigation: run\n  `bundle exec jekyll build` when the repository's Ruby dependencies are\n  available.\n- Both repositories: run `git diff --check`.\n- Always rerun the bundled meta-model comparison after synchronization.\n\nDo not install or upgrade dependencies merely to complete an audit. If a\nrequired existing tool is unavailable, report the exact validation that could\nnot run.\n\n## Report the result\n\nState:\n\n- the two repository roots, branches, and target LSP version;\n- the contract surfaces checked;\n- files changed in each repository;\n- generated artifacts synchronized;\n- validation commands and outcomes;\n- any unresolved divergence or validation gap.\n\nFor audits, report each mismatch with the specification evidence, Node\nevidence, wire or API impact, and the recommended authoritative fix. Do not\nclaim consistency when only the meta-model files were compared.\n"},"files":{".github/skills/lsp-node-protocol-consistency/references/consistency-checklist.md":"# Consistency checklist\n\nUse this reference after identifying the feature or types in scope.\n\n## Surface map\n\n| Concern | Specification repository | Node repository |\n| --- | --- | --- |\n| Current version | `_data/specifications.yml` | `protocol/package.json` and meta-model metadata |\n| Feature prose and snippets | `_specifications/lsp/<version>/<area>/<feature>.md` | Relevant files below |\n| Shared wire data | Feature or `types/*.md` pages | `types/src/main.ts` |\n| Request or notification | Feature page | `protocol/src/common/protocol.<feature>.ts` or `protocol.ts` |\n| Capabilities | Feature page and `general/initialize.md` | `ClientCapabilities` and `ServerCapabilities` in protocol sources |\n| Public protocol exports | TypeScript snippets imply public names | `protocol/src/common/protocol.ts` and `api.ts` |\n| Client integration | Normative client behavior | `client/src/common/`, converters, middleware, and tests |\n| Server integration | Normative server behavior | `server/src/common/` and tests |\n| Machine-readable contract | `metaModel/metaModel.json` | Generated `protocol/metaModel.json` |\n| Meta-model types | `metaModel/metaModel.ts` | `tools/src/metaModel.ts` |\n| Meta-model schema | `metaModel/metaModel.schema.json` | Generated `protocol/metaModel.schema.json` |\n| Navigation and release notes | Version TOC and change log | Usually not applicable |\n\nThe Node meta-model generator reads the protocol TypeScript program, including\ntypes imported from `@vscode/languageserver-types`. A missing generated entry\ncan therefore originate in either `types/src/main.ts`, protocol declarations,\nexports, or generator-recognition conventions.\n\n## Request and notification checks\n\n- Exact method string, including `$`, slashes, and casing.\n- Correct direction.\n- Request versus notification.\n- Parameter type and whether parameters may be omitted.\n- Result type, including `null`, arrays, and unions.\n- Partial-result and work-done-progress types.\n- Error-data type when protocol-specific.\n- Registration-options type.\n- Client capability path.\n- Server capability path.\n- Static registration identifier support.\n- Dynamic registration support.\n- Cancellation and retrigger behavior stated in prose.\n\n## Type checks\n\n- Public type name and link target.\n- Structure inheritance or intersection members.\n- Every property name and documentation.\n- Required versus optional.\n- Nullable versus non-nullable.\n- Primitive kind, especially `integer`, `uinteger`, and `decimal`.\n- Array element type and map key/value types.\n- Union alternatives and literal values.\n- Enum representation and exact numeric or string values.\n- Recursive references and aliases.\n- Serialization shape; helper factories and guards must not change it.\n- `@since`, `@deprecated`, and `@proposed` metadata.\n\nType aliases and interfaces can be equivalent. Compare their resulting wire\nshapes rather than requiring the same TypeScript syntax. Conversely, do not\ntreat `property?: T` as equivalent to `property: T | null`.\n\n## Capability and registration checks\n\n- Client capability is nested under the documented path.\n- Server capability uses the documented property and value type.\n- Boolean shorthand is supported only when the specification permits it.\n- Registration options include the documented selector and static ID mixins.\n- The message descriptor uses the same registration-options type.\n- Client code advertises and consumes the capability consistently.\n- Server APIs expose handlers only for valid directions.\n\n## Stability and version checks\n\n- New stable additions carry the intended `@since <major>.<minor>.<patch>`.\n- Proposed declarations remain marked proposed on both sides.\n- Finalizing a proposal removes proposal markers and moves/exports declarations\n  according to established Node conventions.\n- Deprecation text names the replacement when one exists.\n- Patch-level corrections do not accidentally claim a new minor version.\n- Previous specification versions stay unchanged unless the task explicitly\n  corrects historical documentation.\n- Package version bumps are release work and are not implied by a contract\n  consistency fix.\n\n## Runtime integration checks\n\nApply these only when the Node client or server implements the feature:\n\n- Public feature registration and initialization.\n- Protocol-to-editor and editor-to-protocol conversion.\n- Middleware or handler signatures.\n- Cancellation-token propagation.\n- Partial-result and progress handling.\n- Dynamic registration and unregistration.\n- Capability negotiation and fallback behavior.\n- Node and browser entry-point exposure where applicable.\n- Focused tests for serialization, conversion, registration, and handlers.\n\n## Completion gate\n\nConsistency is established only when:\n\n1. the normative prose and snippets describe the intended behavior;\n2. Node wire declarations encode the same contract;\n3. applicable client/server behavior honors it;\n4. generated Node meta-model artifacts are current;\n5. specification meta-model mirrors match semantically;\n6. affected builds, lints, and tests pass;\n7. no unexplained divergence remains in either repository.\n",".github/skills/lsp-node-protocol-consistency/SKILL.md":"---\nname: lsp-node-protocol-consistency\ndescription: Keeps the Language Server Protocol specification and the vscode-languageserver-node TypeScript implementation aligned. Use when adding, changing, reviewing, or auditing LSP requests, notifications, capabilities, registration options, wire types, proposed or final status, since tags, meta-model data, or related documentation across microsoft/language-server-protocol and microsoft/vscode-languageserver-node.\nlicense: MIT\ncompatibility: Requires local checkouts of microsoft/language-server-protocol and microsoft/vscode-languageserver-node, plus Node.js, npm, and git. Ruby and Bundler are optional for building the specification site.\nmetadata:\n  author: microsoft\n  version: \"1.0\"\n---\n\n# LSP Node and specification consistency\n\nMaintain one coherent LSP wire contract across the normative specification and\nthe Node implementation. Do not equate textual similarity with compatibility:\nTypeScript aliases, interfaces, intersections, helper namespaces, and factories\ncan differ while describing the same wire shape.\n\n## Establish the scope\n\n1. Locate both repository roots instead of assuming fixed directory names:\n   - The specification root contains `_data/specifications.yml`.\n   - The Node root contains `protocol/package.json`, `types/src/main.ts`, and\n     `tools/src/metaModel.ts`.\n2. Read `git status --short --branch` in both repositories before editing.\n   Preserve unrelated changes. If task files already have conflicting edits,\n   ask how to proceed.\n3. Read `_data/specifications.yml` to identify the current LSP version unless\n   the user named a version. Do not update previous versions unless the task is\n   explicitly a historical correction.\n4. Determine whether the task is:\n   - an audit or review,\n   - a specification-first protocol change,\n   - an implementation correction, or\n   - synchronization of an already agreed contract.\n5. Identify the exact methods, capability paths, types, properties, enum\n   values, and documentation affected. Search both repositories for all of\n   them before changing files.\n\nIf the intended wire behavior is ambiguous or the repositories disagree in a\nway the task does not resolve, stop and ask which behavior is intended.\n\n## Apply source-of-truth rules\n\n- The specification prose defines normative protocol behavior.\n- However the implementation is the point of truth of the actual behavior. The\n  protocol should follow the implementation if not noted otherwise.\n- The Node TypeScript sources define the Node API and generate the meta model.\n- The specification's `metaModel.json`, `metaModel.ts`, and\n  `metaModel.schema.json` are mirrors of artifacts from the Node repository.\n- Never resolve a disagreement by blindly copying one side. Establish the\n  intended contract, update the authoritative source for each concern, and\n  then synchronize derived artifacts.\n\nRead [the consistency checklist](references/consistency-checklist.md) for the\nsurface map and the invariants that must be checked.\n\n## Build a contract matrix\n\nFor every affected request, notification, or type, record and compare:\n\n- method string and message direction;\n- parameter, result, error data, partial result, and registration types;\n- client and server capability paths;\n- static and dynamic registration behavior;\n- property names, optionality, nullability, arrays, maps, unions, and literals;\n- numeric or string enum values;\n- `@since`, deprecation, and proposed/final status;\n- behavioral requirements stated only in prose;\n- public exports and, where applicable, client/server feature wiring.\n\nTreat these distinctions as wire-significant:\n\n- omitted versus present with `null`;\n- optional versus required;\n- integer versus decimal;\n- an array versus a single value;\n- a literal value versus a general primitive;\n- client-to-server versus server-to-client versus both;\n- static capability advertisement versus dynamic registration.\n\n## Make coordinated changes\n\nWhen the task calls for edits, use an analogous completed feature as a pattern\nand update every applicable surface.\n\n### Specification repository\n\nUpdate the current version under `_specifications/lsp/<version>/`:\n\n- the feature or shared-type Markdown;\n- `specification.md` when a new topic must be included;\n- `_data/specification-<major>-<minor>-toc.yml` when navigation changes;\n- versioned message includes when the change affects shared messages;\n- the change log when the protocol version gains a user-visible feature.\n\nKeep prose examples and TypeScript snippets semantically aligned. Preserve\nanchors and links when moving or renaming content.\n\n### Node repository\n\nUpdate only the layers required by the change:\n\n- `types/src/main.ts` for serializable LSP data types and their public helpers;\n- `protocol/src/common/protocol.ts` for shared protocol types, capabilities,\n  imports, and exports;\n- `protocol/src/common/protocol.<feature>.ts` for feature-specific messages;\n- `protocol/src/common/api.ts` for public API exposure when needed;\n- `client/src/common/` for client capability, registration, conversion, and\n  middleware support;\n- `server/src/common/` for typed server handlers and feature exposure;\n- focused unit or integration tests for changed runtime behavior.\n\nNot every wire change requires client or server feature code. Explain why a\nlayer is not applicable rather than adding empty plumbing.\n\n## Regenerate and synchronize the meta model\n\nAfter changing Node protocol or type sources:\n\n1. Compile the affected Node workspaces.\n2. From the Node `protocol` workspace, run `npm run compile:metaModelTool`.\n3. From the Node repository root, run:\n   - `npm run generate:metaModel`\n   - `npm run generate:metaModelSchema`\n4. Inspect the generated diff. Unexpected additions, omissions, reordered\n   declarations, or lost documentation usually indicate an implementation or\n   generator-modeling error; fix the source instead of hand-editing generated\n   JSON.\n5. Copy the intended generated artifacts to the current specification:\n   - `protocol/metaModel.json` to\n     `_specifications/lsp/<version>/metaModel/metaModel.json`;\n   - `tools/src/metaModel.ts` to\n     `_specifications/lsp/<version>/metaModel/metaModel.ts`;\n   - `protocol/metaModel.schema.json` to\n     `_specifications/lsp/<version>/metaModel/metaModel.schema.json`.\n6. Run the bundled comparison from the specification root:\n\n   `node .github/skills/lsp-node-protocol-consistency/scripts/compare-meta-model.mjs --node-repo <node-repository-root>`\n\nThe comparison is read-only. It compares JSON semantically so irrelevant\nobject-key ordering does not create false failures, while array ordering and\nall values remain significant.\n\nMeta-model equality is necessary but not sufficient. It does not prove that\nnormative prose, examples, client/server behavior, or runtime helpers agree.\n\n## Validate\n\nUse the smallest existing commands that cover the changed layers, escalating\nonly when needed:\n\n- Node type changes: `npm run compile:types`, then the `types` lint and tests.\n- Protocol changes: `npm run compile:protocol`, then the `protocol` lint and\n  Node tests.\n- Server changes: compile, lint, and test the `server` workspace.\n- Client changes: compile and lint `client`; run the focused\n  `client-node-tests` integration tests that exercise the feature.\n- Specification Markdown, includes, or navigation: run\n  `bundle exec jekyll build` when the repository's Ruby dependencies are\n  available.\n- Both repositories: run `git diff --check`.\n- Always rerun the bundled meta-model comparison after synchronization.\n\nDo not install or upgrade dependencies merely to complete an audit. If a\nrequired existing tool is unavailable, report the exact validation that could\nnot run.\n\n## Report the result\n\nState:\n\n- the two repository roots, branches, and target LSP version;\n- the contract surfaces checked;\n- files changed in each repository;\n- generated artifacts synchronized;\n- validation commands and outcomes;\n- any unresolved divergence or validation gap.\n\nFor audits, report each mismatch with the specification evidence, Node\nevidence, wire or API impact, and the recommended authoritative fix. Do not\nclaim consistency when only the meta-model files were compared.\n"},"items":[{"name":"consistency-checklist.md","path":".github/skills/lsp-node-protocol-consistency/references/consistency-checklist.md","rawUrl":"https://raw.githubusercontent.com/microsoft/language-server-protocol/HEAD/.github/skills/lsp-node-protocol-consistency/references/consistency-checklist.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# Consistency checklist\n\nUse this reference after identifying the feature or types in scope.\n\n## Surface map\n\n| Concern | Specification repository | Node repository |\n| --- | --- | --- |\n| Current version | `_data/specifications.yml` | `protocol/package.json` and meta-model metadata |\n| Feature prose and snippets | `_specifications/lsp/<version>/<area>/<feature>.md` | Relevant files below |\n| Shared wire data | Feature or `types/*.md` pages | `types/src/main.ts` |\n| Request or notification | Feature page | `protocol/src/common/protocol.<feature>.ts` or `protocol.ts` |\n| Capabilities | Feature page and `general/initialize.md` | `ClientCapabilities` and `ServerCapabilities` in protocol sources |\n| Public protocol exports | TypeScript snippets imply public names | `protocol/src/common/protocol.ts` and `api.ts` |\n| Client integration | Normative client behavior | `client/src/common/`, converters, middleware, and tests |\n| Server integration | Normative server behavior | `server/src/common/` and tests |\n| Machine-readable contract | `metaModel/metaModel.json` | Generated `protocol/metaModel.json` |\n| Meta-model types | `metaModel/metaModel.ts` | `tools/src/metaModel.ts` |\n| Meta-model schema | `metaModel/metaModel.schema.json` | Generated `protocol/metaModel.schema.json` |\n| Navigation and release notes | Version TOC and change log | Usually not applicable |\n\nThe Node meta-model generator reads the protocol TypeScript program, including\ntypes imported from `@vscode/languageserver-types`. A missing generated entry\ncan therefore originate in either `types/src/main.ts`, protocol declarations,\nexports, or generator-recognition conventions.\n\n## Request and notification checks\n\n- Exact method string, including `$`, slashes, and casing.\n- Correct direction.\n- Request versus notification.\n- Parameter type and whether parameters may be omitted.\n- Result type, including `null`, arrays, and unions.\n- Partial-result and work-done-progress types.\n- Error-data type when protocol-specific.\n- Registration-options type.\n- Client capability path.\n- Server capability path.\n- Static registration identifier support.\n- Dynamic registration support.\n- Cancellation and retrigger behavior stated in prose.\n\n## Type checks\n\n- Public type name and link target.\n- Structure inheritance or intersection members.\n- Every property name and documentation.\n- Required versus optional.\n- Nullable versus non-nullable.\n- Primitive kind, especially `integer`, `uinteger`, and `decimal`.\n- Array element type and map key/value types.\n- Union alternatives and literal values.\n- Enum representation and exact numeric or string values.\n- Recursive references and aliases.\n- Serialization shape; helper factories and guards must not change it.\n- `@since`, `@deprecated`, and `@proposed` metadata.\n\nType aliases and interfaces can be equivalent. Compare their resulting wire\nshapes rather than requiring the same TypeScript syntax. Conversely, do not\ntreat `property?: T` as equivalent to `property: T | null`.\n\n## Capability and registration checks\n\n- Client capability is nested under the documented path.\n- Server capability uses the documented property and value type.\n- Boolean shorthand is supported only when the specification permits it.\n- Registration options include the documented selector and static ID mixins.\n- The message descriptor uses the same registration-options type.\n- Client code advertises and consumes the capability consistently.\n- Server APIs expose handlers only for valid directions.\n\n## Stability and version checks\n\n- New stable additions carry the intended `@since <major>.<minor>.<patch>`.\n- Proposed declarations remain marked proposed on both sides.\n- Finalizing a proposal removes proposal markers and moves/exports declarations\n  according to established Node conventions.\n- Deprecation text names the replacement when one exists.\n- Patch-level corrections do not accidentally claim a new minor version.\n- Previous specification versions stay unchanged unless the task explicitly\n  corrects historical documentation.\n- Package version bumps are release work and are not implied by a contract\n  consistency fix.\n\n## Runtime integration checks\n\nApply these only when the Node client or server implements the feature:\n\n- Public feature registration and initialization.\n- Protocol-to-editor and editor-to-protocol conversion.\n- Middleware or handler signatures.\n- Cancellation-token propagation.\n- Partial-result and progress handling.\n- Dynamic registration and unregistration.\n- Capability negotiation and fallback behavior.\n- Node and browser entry-point exposure where applicable.\n- Focused tests for serialization, conversion, registration, and handlers.\n\n## Completion gate\n\nConsistency is established only when:\n\n1. the normative prose and snippets describe the intended behavior;\n2. Node wire declarations encode the same contract;\n3. applicable client/server behavior honors it;\n4. generated Node meta-model artifacts are current;\n5. specification meta-model mirrors match semantically;\n6. affected builds, lints, and tests pass;\n7. no unexplained divergence remains in either repository.\n","isInternal":false,"tokens":1001,"sizeBytes":5123},{"name":"SKILL.md","path":".github/skills/lsp-node-protocol-consistency/SKILL.md","rawUrl":"https://raw.githubusercontent.com/microsoft/language-server-protocol/HEAD/.github/skills/lsp-node-protocol-consistency/SKILL.md","title":"lsp-node-protocol-consistency","category":"anthropic-skill","format":"markdown","content":"---\nname: lsp-node-protocol-consistency\ndescription: Keeps the Language Server Protocol specification and the vscode-languageserver-node TypeScript implementation aligned. Use when adding, changing, reviewing, or auditing LSP requests, notifications, capabilities, registration options, wire types, proposed or final status, since tags, meta-model data, or related documentation across microsoft/language-server-protocol and microsoft/vscode-languageserver-node.\nlicense: MIT\ncompatibility: Requires local checkouts of microsoft/language-server-protocol and microsoft/vscode-languageserver-node, plus Node.js, npm, and git. Ruby and Bundler are optional for building the specification site.\nmetadata:\n  author: microsoft\n  version: \"1.0\"\n---\n\n# LSP Node and specification consistency\n\nMaintain one coherent LSP wire contract across the normative specification and\nthe Node implementation. Do not equate textual similarity with compatibility:\nTypeScript aliases, interfaces, intersections, helper namespaces, and factories\ncan differ while describing the same wire shape.\n\n## Establish the scope\n\n1. Locate both repository roots instead of assuming fixed directory names:\n   - The specification root contains `_data/specifications.yml`.\n   - The Node root contains `protocol/package.json`, `types/src/main.ts`, and\n     `tools/src/metaModel.ts`.\n2. Read `git status --short --branch` in both repositories before editing.\n   Preserve unrelated changes. If task files already have conflicting edits,\n   ask how to proceed.\n3. Read `_data/specifications.yml` to identify the current LSP version unless\n   the user named a version. Do not update previous versions unless the task is\n   explicitly a historical correction.\n4. Determine whether the task is:\n   - an audit or review,\n   - a specification-first protocol change,\n   - an implementation correction, or\n   - synchronization of an already agreed contract.\n5. Identify the exact methods, capability paths, types, properties, enum\n   values, and documentation affected. Search both repositories for all of\n   them before changing files.\n\nIf the intended wire behavior is ambiguous or the repositories disagree in a\nway the task does not resolve, stop and ask which behavior is intended.\n\n## Apply source-of-truth rules\n\n- The specification prose defines normative protocol behavior.\n- However the implementation is the point of truth of the actual behavior. The\n  protocol should follow the implementation if not noted otherwise.\n- The Node TypeScript sources define the Node API and generate the meta model.\n- The specification's `metaModel.json`, `metaModel.ts`, and\n  `metaModel.schema.json` are mirrors of artifacts from the Node repository.\n- Never resolve a disagreement by blindly copying one side. Establish the\n  intended contract, update the authoritative source for each concern, and\n  then synchronize derived artifacts.\n\nRead [the consistency checklist](references/consistency-checklist.md) for the\nsurface map and the invariants that must be checked.\n\n## Build a contract matrix\n\nFor every affected request, notification, or type, record and compare:\n\n- method string and message direction;\n- parameter, result, error data, partial result, and registration types;\n- client and server capability paths;\n- static and dynamic registration behavior;\n- property names, optionality, nullability, arrays, maps, unions, and literals;\n- numeric or string enum values;\n- `@since`, deprecation, and proposed/final status;\n- behavioral requirements stated only in prose;\n- public exports and, where applicable, client/server feature wiring.\n\nTreat these distinctions as wire-significant:\n\n- omitted versus present with `null`;\n- optional versus required;\n- integer versus decimal;\n- an array versus a single value;\n- a literal value versus a general primitive;\n- client-to-server versus server-to-client versus both;\n- static capability advertisement versus dynamic registration.\n\n## Make coordinated changes\n\nWhen the task calls for edits, use an analogous completed feature as a pattern\nand update every applicable surface.\n\n### Specification repository\n\nUpdate the current version under `_specifications/lsp/<version>/`:\n\n- the feature or shared-type Markdown;\n- `specification.md` when a new topic must be included;\n- `_data/specification-<major>-<minor>-toc.yml` when navigation changes;\n- versioned message includes when the change affects shared messages;\n- the change log when the protocol version gains a user-visible feature.\n\nKeep prose examples and TypeScript snippets semantically aligned. Preserve\nanchors and links when moving or renaming content.\n\n### Node repository\n\nUpdate only the layers required by the change:\n\n- `types/src/main.ts` for serializable LSP data types and their public helpers;\n- `protocol/src/common/protocol.ts` for shared protocol types, capabilities,\n  imports, and exports;\n- `protocol/src/common/protocol.<feature>.ts` for feature-specific messages;\n- `protocol/src/common/api.ts` for public API exposure when needed;\n- `client/src/common/` for client capability, registration, conversion, and\n  middleware support;\n- `server/src/common/` for typed server handlers and feature exposure;\n- focused unit or integration tests for changed runtime behavior.\n\nNot every wire change requires client or server feature code. Explain why a\nlayer is not applicable rather than adding empty plumbing.\n\n## Regenerate and synchronize the meta model\n\nAfter changing Node protocol or type sources:\n\n1. Compile the affected Node workspaces.\n2. From the Node `protocol` workspace, run `npm run compile:metaModelTool`.\n3. From the Node repository root, run:\n   - `npm run generate:metaModel`\n   - `npm run generate:metaModelSchema`\n4. Inspect the generated diff. Unexpected additions, omissions, reordered\n   declarations, or lost documentation usually indicate an implementation or\n   generator-modeling error; fix the source instead of hand-editing generated\n   JSON.\n5. Copy the intended generated artifacts to the current specification:\n   - `protocol/metaModel.json` to\n     `_specifications/lsp/<version>/metaModel/metaModel.json`;\n   - `tools/src/metaModel.ts` to\n     `_specifications/lsp/<version>/metaModel/metaModel.ts`;\n   - `protocol/metaModel.schema.json` to\n     `_specifications/lsp/<version>/metaModel/metaModel.schema.json`.\n6. Run the bundled comparison from the specification root:\n\n   `node .github/skills/lsp-node-protocol-consistency/scripts/compare-meta-model.mjs --node-repo <node-repository-root>`\n\nThe comparison is read-only. It compares JSON semantically so irrelevant\nobject-key ordering does not create false failures, while array ordering and\nall values remain significant.\n\nMeta-model equality is necessary but not sufficient. It does not prove that\nnormative prose, examples, client/server behavior, or runtime helpers agree.\n\n## Validate\n\nUse the smallest existing commands that cover the changed layers, escalating\nonly when needed:\n\n- Node type changes: `npm run compile:types`, then the `types` lint and tests.\n- Protocol changes: `npm run compile:protocol`, then the `protocol` lint and\n  Node tests.\n- Server changes: compile, lint, and test the `server` workspace.\n- Client changes: compile and lint `client`; run the focused\n  `client-node-tests` integration tests that exercise the feature.\n- Specification Markdown, includes, or navigation: run\n  `bundle exec jekyll build` when the repository's Ruby dependencies are\n  available.\n- Both repositories: run `git diff --check`.\n- Always rerun the bundled meta-model comparison after synchronization.\n\nDo not install or upgrade dependencies merely to complete an audit. If a\nrequired existing tool is unavailable, report the exact validation that could\nnot run.\n\n## Report the result\n\nState:\n\n- the two repository roots, branches, and target LSP version;\n- the contract surfaces checked;\n- files changed in each repository;\n- generated artifacts synchronized;\n- validation commands and outcomes;\n- any unresolved divergence or validation gap.\n\nFor audits, report each mismatch with the specification evidence, Node\nevidence, wire or API impact, and the recommended authoritative fix. Do not\nclaim consistency when only the meta-model files were compared.\n","frontmatter":{"name":"lsp-node-protocol-consistency","description":"Keeps the Language Server Protocol specification and the vscode-languageserver-node TypeScript implementation aligned. Use when adding, changing, reviewing, or auditing LSP requests, notifications, capabilities, registration options, wire types, proposed or final status, since tags, meta-model data, or related documentation across microsoft/language-server-protocol and microsoft/vscode-languageserver-node.","license":"MIT","compatibility":"Requires local checkouts of microsoft/language-server-protocol and microsoft/vscode-languageserver-node, plus Node.js, npm, and git. Ruby and Bundler are optional for building the specification site.","metadata":{"author":"microsoft","version":"1.0"}},"isInternal":false,"tokens":1677,"sizeBytes":8222}],"systemPromptSnippet":"<yakaai_skills repo=\"microsoft/language-server-protocol\">\n<!-- File: .github/skills/lsp-node-protocol-consistency/references/consistency-checklist.md (Tokens: ~1001 | Category: anthropic-skill) -->\n# Consistency checklist\n\nUse this reference after identifying the feature or types in scope.\n\n## Surface map\n\n| Concern | Specification repository | Node repository |\n| --- | --- | --- |\n| Current version | `_data/specifications.yml` | `protocol/package.json` and meta-model metadata |\n| Feature prose and snippets | `_specifications/lsp/<version>/<area>/<feature>.md` | Relevant files below |\n| Shared wire data | Feature or `types/*.md` pages | `types/src/main.ts` |\n| Request or notification | Feature page | `protocol/src/common/protocol.<feature>.ts` or `protocol.ts` |\n| Capabilities | Feature page and `general/initialize.md` | `ClientCapabilities` and `ServerCapabilities` in protocol sources |\n| Public protocol exports | TypeScript snippets imply public names | `protocol/src/common/protocol.ts` and `api.ts` |\n| Client integration | Normative client behavior | `client/src/common/`, converters, middleware, and tests |\n| Server integration | Normative server behavior | `server/src/common/` and tests |\n| Machine-readable contract | `metaModel/metaModel.json` | Generated `protocol/metaModel.json` |\n| Meta-model types | `metaModel/metaModel.ts` | `tools/src/metaModel.ts` |\n| Meta-model schema | `metaModel/metaModel.schema.json` | Generated `protocol/metaModel.schema.json` |\n| Navigation and release notes | Version TOC and change log | Usually not applicable |\n\nThe Node meta-model generator reads the protocol TypeScript program, including\ntypes imported from `@vscode/languageserver-types`. A missing generated entry\ncan therefore originate in either `types/src/main.ts`, protocol declarations,\nexports, or generator-recognition conventions.\n\n## Request and notification checks\n\n- Exact method string, including `$`, slashes, and casing.\n- Correct direction.\n- Request versus notification.\n- Parameter type and whether parameters may be omitted.\n- Result type, including `null`, arrays, and unions.\n- Partial-result and work-done-progress types.\n- Error-data type when protocol-specific.\n- Registration-options type.\n- Client capability path.\n- Server capability path.\n- Static registration identifier support.\n- Dynamic registration support.\n- Cancellation and retrigger behavior stated in prose.\n\n## Type checks\n\n- Public type name and link target.\n- Structure inheritance or intersection members.\n- Every property name and documentation.\n- Required versus optional.\n- Nullable versus non-nullable.\n- Primitive kind, especially `integer`, `uinteger`, and `decimal`.\n- Array element type and map key/value types.\n- Union alternatives and literal values.\n- Enum representation and exact numeric or string values.\n- Recursive references and aliases.\n- Serialization shape; helper factories and guards must not change it.\n- `@since`, `@deprecated`, and `@proposed` metadata.\n\nType aliases and interfaces can be equivalent. Compare their resulting wire\nshapes rather than requiring the same TypeScript syntax. Conversely, do not\ntreat `property?: T` as equivalent to `property: T | null`.\n\n## Capability and registration checks\n\n- Client capability is nested under the documented path.\n- Server capability uses the documented property and value type.\n- Boolean shorthand is supported only when the specification permits it.\n- Registration options include the documented selector and static ID mixins.\n- The message descriptor uses the same registration-options type.\n- Client code advertises and consumes the capability consistently.\n- Server APIs expose handlers only for valid directions.\n\n## Stability and version checks\n\n- New stable additions carry the intended `@since <major>.<minor>.<patch>`.\n- Proposed declarations remain marked proposed on both sides.\n- Finalizing a proposal removes proposal markers and moves/exports declarations\n  according to established Node conventions.\n- Deprecation text names the replacement when one exists.\n- Patch-level corrections do not accidentally claim a new minor version.\n- Previous specification versions stay unchanged unless the task explicitly\n  corrects historical documentation.\n- Package version bumps are release work and are not implied by a contract\n  consistency fix.\n\n## Runtime integration checks\n\nApply these only when the Node client or server implements the feature:\n\n- Public feature registration and initialization.\n- Protocol-to-editor and editor-to-protocol conversion.\n- Middleware or handler signatures.\n- Cancellation-token propagation.\n- Partial-result and progress handling.\n- Dynamic registration and unregistration.\n- Capability negotiation and fallback behavior.\n- Node and browser entry-point exposure where applicable.\n- Focused tests for serialization, conversion, registration, and handlers.\n\n## Completion gate\n\nConsistency is established only when:\n\n1. the normative prose and snippets describe the intended behavior;\n2. Node wire declarations encode the same contract;\n3. applicable client/server behavior honors it;\n4. generated Node meta-model artifacts are current;\n5. specification meta-model mirrors match semantically;\n6. affected builds, lints, and tests pass;\n7. no unexplained divergence remains in either repository.\n\n<!-- File: .github/skills/lsp-node-protocol-consistency/SKILL.md (Tokens: ~1677 | Category: anthropic-skill) -->\n---\nname: lsp-node-protocol-consistency\ndescription: Keeps the Language Server Protocol specification and the vscode-languageserver-node TypeScript implementation aligned. Use when adding, changing, reviewing, or auditing LSP requests, notifications, capabilities, registration options, wire types, proposed or final status, since tags, meta-model data, or related documentation across microsoft/language-server-protocol and microsoft/vscode-languageserver-node.\nlicense: MIT\ncompatibility: Requires local checkouts of microsoft/language-server-protocol and microsoft/vscode-languageserver-node, plus Node.js, npm, and git. Ruby and Bundler are optional for building the specification site.\nmetadata:\n  author: microsoft\n  version: \"1.0\"\n---\n\n# LSP Node and specification consistency\n\nMaintain one coherent LSP wire contract across the normative specification and\nthe Node implementation. Do not equate textual similarity with compatibility:\nTypeScript aliases, interfaces, intersections, helper namespaces, and factories\ncan differ while describing the same wire shape.\n\n## Establish the scope\n\n1. Locate both repository roots instead of assuming fixed directory names:\n   - The specification root contains `_data/specifications.yml`.\n   - The Node root contains `protocol/package.json`, `types/src/main.ts`, and\n     `tools/src/metaModel.ts`.\n2. Read `git status --short --branch` in both repositories before editing.\n   Preserve unrelated changes. If task files already have conflicting edits,\n   ask how to proceed.\n3. Read `_data/specifications.yml` to identify the current LSP version unless\n   the user named a version. Do not update previous versions unless the task is\n   explicitly a historical correction.\n4. Determine whether the task is:\n   - an audit or review,\n   - a specification-first protocol change,\n   - an implementation correction, or\n   - synchronization of an already agreed contract.\n5. Identify the exact methods, capability paths, types, properties, enum\n   values, and documentation affected. Search both repositories for all of\n   them before changing files.\n\nIf the intended wire behavior is ambiguous or the repositories disagree in a\nway the task does not resolve, stop and ask which behavior is intended.\n\n## Apply source-of-truth rules\n\n- The specification prose defines normative protocol behavior.\n- However the implementation is the point of truth of the actual behavior. The\n  protocol should follow the implementation if not noted otherwise.\n- The Node TypeScript sources define the Node API and generate the meta model.\n- The specification's `metaModel.json`, `metaModel.ts`, and\n  `metaModel.schema.json` are mirrors of artifacts from the Node repository.\n- Never resolve a disagreement by blindly copying one side. Establish the\n  intended contract, update the authoritative source for each concern, and\n  then synchronize derived artifacts.\n\nRead [the consistency checklist](references/consistency-checklist.md) for the\nsurface map and the invariants that must be checked.\n\n## Build a contract matrix\n\nFor every affected request, notification, or type, record and compare:\n\n- method string and message direction;\n- parameter, result, error data, partial result, and registration types;\n- client and server capability paths;\n- static and dynamic registration behavior;\n- property names, optionality, nullability, arrays, maps, unions, and literals;\n- numeric or string enum values;\n- `@since`, deprecation, and proposed/final status;\n- behavioral requirements stated only in prose;\n- public exports and, where applicable, client/server feature wiring.\n\nTreat these distinctions as wire-significant:\n\n- omitted versus present with `null`;\n- optional versus required;\n- integer versus decimal;\n- an array versus a single value;\n- a literal value versus a general primitive;\n- client-to-server versus server-to-client versus both;\n- static capability advertisement versus dynamic registration.\n\n## Make coordinated changes\n\nWhen the task calls for edits, use an analogous completed feature as a pattern\nand update every applicable surface.\n\n### Specification repository\n\nUpdate the current version under `_specifications/lsp/<version>/`:\n\n- the feature or shared-type Markdown;\n- `specification.md` when a new topic must be included;\n- `_data/specification-<major>-<minor>-toc.yml` when navigation changes;\n- versioned message includes when the change affects shared messages;\n- the change log when the protocol version gains a user-visible feature.\n\nKeep prose examples and TypeScript snippets semantically aligned. Preserve\nanchors and links when moving or renaming content.\n\n### Node repository\n\nUpdate only the layers required by the change:\n\n- `types/src/main.ts` for serializable LSP data types and their public helpers;\n- `protocol/src/common/protocol.ts` for shared protocol types, capabilities,\n  imports, and exports;\n- `protocol/src/common/protocol.<feature>.ts` for feature-specific messages;\n- `protocol/src/common/api.ts` for public API exposure when needed;\n- `client/src/common/` for client capability, registration, conversion, and\n  middleware support;\n- `server/src/common/` for typed server handlers and feature exposure;\n- focused unit or integration tests for changed runtime behavior.\n\nNot every wire change requires client or server feature code. Explain why a\nlayer is not applicable rather than adding empty plumbing.\n\n## Regenerate and synchronize the meta model\n\nAfter changing Node protocol or type sources:\n\n1. Compile the affected Node workspaces.\n2. From the Node `protocol` workspace, run `npm run compile:metaModelTool`.\n3. From the Node repository root, run:\n   - `npm run generate:metaModel`\n   - `npm run generate:metaModelSchema`\n4. Inspect the generated diff. Unexpected additions, omissions, reordered\n   declarations, or lost documentation usually indicate an implementation or\n   generator-modeling error; fix the source instead of hand-editing generated\n   JSON.\n5. Copy the intended generated artifacts to the current specification:\n   - `protocol/metaModel.json` to\n     `_specifications/lsp/<version>/metaModel/metaModel.json`;\n   - `tools/src/metaModel.ts` to\n     `_specifications/lsp/<version>/metaModel/metaModel.ts`;\n   - `protocol/metaModel.schema.json` to\n     `_specifications/lsp/<version>/metaModel/metaModel.schema.json`.\n6. Run the bundled comparison from the specification root:\n\n   `node .github/skills/lsp-node-protocol-consistency/scripts/compare-meta-model.mjs --node-repo <node-repository-root>`\n\nThe comparison is read-only. It compares JSON semantically so irrelevant\nobject-key ordering does not create false failures, while array ordering and\nall values remain significant.\n\nMeta-model equality is necessary but not sufficient. It does not prove that\nnormative prose, examples, client/server behavior, or runtime helpers agree.\n\n## Validate\n\nUse the smallest existing commands that cover the changed layers, escalating\nonly when needed:\n\n- Node type changes: `npm run compile:types`, then the `types` lint and tests.\n- Protocol changes: `npm run compile:protocol`, then the `protocol` lint and\n  Node tests.\n- Server changes: compile, lint, and test the `server` workspace.\n- Client changes: compile and lint `client`; run the focused\n  `client-node-tests` integration tests that exercise the feature.\n- Specification Markdown, includes, or navigation: run\n  `bundle exec jekyll build` when the repository's Ruby dependencies are\n  available.\n- Both repositories: run `git diff --check`.\n- Always rerun the bundled meta-model comparison after synchronization.\n\nDo not install or upgrade dependencies merely to complete an audit. If a\nrequired existing tool is unavailable, report the exact validation that could\nnot run.\n\n## Report the result\n\nState:\n\n- the two repository roots, branches, and target LSP version;\n- the contract surfaces checked;\n- files changed in each repository;\n- generated artifacts synchronized;\n- validation commands and outcomes;\n- any unresolved divergence or validation gap.\n\nFor audits, report each mismatch with the specification evidence, Node\nevidence, wire or API impact, and the recommended authoritative fix. Do not\nclaim consistency when only the meta-model files were compared.\n</yakaai_skills>"}