[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M699A6ZCXQ7HC94Z7HC8DMMG":3,"skill-same:01M699A6ZCXQ7HC94Z7HC8DMMG":76},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":47,"linkOnly":48,"markdownContent":49,"markdownBody":50,"frontMatter":51,"refName":52,"commitSha":53,"skillDirectory":54,"forksCount":55,"repositoryHtmlUrl":56,"repositoryHomepageUrl":57,"ownerHtmlUrl":58,"ownerBlogUrl":59,"ownerDescription":60,"updatedAt":61,"install":62,"resources":75},"01M699A6ZCXQ7HC94Z7HC8DMMG","customizations-in-the-agent-host",null,"Architecture and hard-won debugging lessons for customization enablement (plugins, MCP servers, agents, skills, instructions) in the agent host. Use when changing how customizations are discovered, published, enabled\u002Fdisabled, or handed to a provider SDK; when a customization shows the wrong enabled state in the UI; or when a disabled MCP server or plugin is still reaching the model.","microsoft\u002Fvscode","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M6998NK2WED5M549DX06VBCH",195271,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fcustomizations-in-the-agent-host\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46],"customizations in the agent host","host","server","when","lessons","for","enablement","provider","use","customization","instructions","model","how","MCP","ui","plugins","mcp servers","state","debugging","plugin","architecture","mcp server","sdk","2026-11-10 10:12:30",false,"---\nname: customizations-in-the-agent-host\ndescription: Architecture and hard-won debugging lessons for customization enablement (plugins, MCP servers, agents, skills, instructions) in the agent host. Use when changing how customizations are discovered, published, enabled\u002Fdisabled, or handed to a provider SDK; when a customization shows the wrong enabled state in the UI; or when a disabled MCP server or plugin is still reaching the model.\n---\n\n# Customizations in the Agent Host\n\nCustomizations are the plugins, MCP servers, agents, skills and instructions that an agent-host session exposes to a model. This skill covers **enablement**: how a customization's on\u002Foff state is decided, stored, published and enforced.\n\nRead this before changing anything in:\n\n- `src\u002Fvs\u002Fplatform\u002FagentHost\u002Fnode\u002FagentHostCustomizationEnablementService.ts`\n- `src\u002Fvs\u002Fplatform\u002FagentHost\u002Fnode\u002Fshared\u002FcustomizationEnablementGate.ts`\n- `src\u002Fvs\u002Fplatform\u002FagentHost\u002Fcommon\u002FcustomizationEnablement.ts`\n- the per-provider customization paths under `node\u002Fcopilot\u002F`, `node\u002Fclaude\u002F`, `node\u002Fcodex\u002F`\n\n## The mental model\n\n### Enablement is a list of scoped decisions, not a boolean\n\nA plugin or MCP server carries `enablement?: CustomizationEnablement[]` — an ordered list of decisions, most specific first:\n\n| Kind | Owner | Meaning |\n|---|---|---|\n| `Session` | agent host | this session only |\n| `Workspace` | agent host | this working directory (carries `uri`) |\n| `Global` | client, unless the host discovered it | everywhere |\n\n`isCustomizationEnabled()` picks the first entry; absent entries inherit from the next scope out, and an absent list means enabled. Never re-add a parallel `enabled` boolean to plugins or MCP servers — a second source of truth is what this design exists to remove. (`DirectoryCustomization` legitimately keeps a plain `enabled`; consumers derive its state through `isCustomizationEnabled()` all the same.)\n\n### Who owns `Global`\n\nThe host owns `Global` for anything it **discovered**, even when that thing lives inside a plugin the client forwarded. The client owns `Global` only for what it actually **bundled**. The discriminator is `childEnablement` — *not* `clientId`. A plugin whose `childEnablement` record has a key for a child MCP server means \"the client bundled this child and owns its global decision\"; anything else the host discovered by parsing the plugin directory.\n\n### The overlay model\n\nThis is the single most important invariant, and getting it wrong caused a self-defeating write that silently erased user decisions:\n\n> The client's value is the **base**. Host decisions layer **on top**. \"Store only what differs\" compares against that base — never against a hardcoded `true`.\n\nConcretely, in `agentHostCustomizationEnablementService.ts`:\n\n- `_clientGlobalEnablement` is the in-memory **base**, per session. `_setClientGlobal` writes here and **must never touch `_persistent`**.\n- `_persistent` holds only host-owned decisions that differ from the base.\n- Inheritance runs host → base → `DEFAULT_CUSTOMIZATION_ENABLED` (`_globalEnablement`, `_workspaceInheritedEnablement`).\n- `_setPersistentDecision` deletes a decision that matches its inherited value, so the UI can restore inheritance without a third \"Inherit\" action.\n\nKeeping these separate is what stops this loop: `replaceEnablement` → synchronous republish → client's stale `[{global,true}]` → `_setClientGlobal` → \"store only what differs\" deletes the entry just written.\n\n### Identity must not depend on tree position\n\nAn MCP server's storage key is derived from `owningPluginUri`, never from where it happened to appear in the published tree. The same server discovered top-level (`mcpServers#azure`) and nested under a plugin (`\u003CpluginURI>#mcp=azure`) must produce **one** key, or a decision written in one session is invisible to the next. `targetForMcpServer()` and `withOwningPluginUri()` in the gate are the only supported way to build that target.\n\n### Customization URIs have an author\n\nA client-published plugin's `uri` is in that client's URI space, but its `children` are host-authored paths into the host's materialized copy. Resolve them with `getAgentHostCustomizationUri` and treat other clients' plugins as opaque. A same-host plugin is published as `vscode-agent-host-file:`; match it to its client source through `id` or the decoded URI, never the raw published URI. See [Agent Host URI spaces](..\u002F..\u002Finstructions\u002Fagent-host-uri-spaces.instructions.md).\n\n### Pending means fail closed — but pending must be transient\n\n`resolve()` returns `{kind:'pending'}` when the session isn't initialized yet (`reason: 'session'`) or the working directory isn't known (`reason: 'workingDirectory'`). `resolveCustomizationEnablement()` records those in `pendingCustomizationIds`, and `isCustomizationSdkEligible()` makes SDK-boundary consumers **fail closed**.\n\nTwo rules follow:\n\n1. Never \"fix\" a pending customization by defaulting it to enabled.\n2. Never cache the pending verdict. Pending is a *temporary* state; recompute it, and republish when the enablement service settles. A cached `pendingEnablement: true` silently drops a plugin forever.\n\nA pending child MCP server also marks its **containing plugin** pending, because a plugin directory can cause the SDK to discover the child on its own.\n\n## The rule that prevents most bugs\n\n> **Every publication, emit and SDK-handoff path must go through resolution.**\n\nThree separate production bugs on this feature came from paths that skipped it (four sites in `copilotAgent`, one in `mcpCustomizationController`, plus the post-startup reconcile). When you add a new place that publishes a customization or hands one to a provider, route it through `resolveCustomizationEnablement()` — do not read a stored snapshot.\n\nThe corollary: **state computed once must be rebuilt when its inputs change.** Merged per-client enablement maps that are only appended to will leak stale decisions onto a newly parsed plugin with the same URI.\n\n## Enforcement is per-provider, and they differ\n\n| Provider | Launch | Mid-session |\n|---|---|---|\n| Copilot | `disabledMcpServers` on `SessionConfig` at open\u002Fresume | `rpc.mcp.enable` \u002F `rpc.mcp.disable` |\n| Claude | session options at materialize | live reconcile |\n| Codex | MCP servers supplied only at `thread\u002Fstart` \u002F resume | **not possible** — documented limitation |\n\nEnforcement traps:\n\n- The post-startup reconcile runs ~800 ms after launch. Anything gated *only* there can still start, and request authentication, during the launch window. Gate at launch too.\n- The SDK's `not_configured` status must **not** be translated as `enabled: true`. That bug made a correct \"skip this disabled server\" decision look like \"enable it\".\n- Copilot launch gating must include names from user `mcp.config.list`, not only the client snapshot. Reconcile and authentication also resolve newly discovered names before the host retains them; later publication must not turn an inherited enabled default into explicit intent to enable an SDK-configured-disabled server.\n- Root MCP customization IDs use the owning AHP session ID, not its SDK backing ID. On restoration, derive declared MCP names from the applied root\u002Fplugin definitions, never from the retained host-published runtime inventory.\n- Connection lifecycle (`pending`, `connected`, `stopped`) is not enablement intent. Confirm external toggles against passive `mcp.listConfigured` enablement, ignoring stale asynchronous snapshots and host-requested changes.\n\nClient-provided MCP servers (ones the client bundled rather than the host discovering) must route their global Disable to the **client**, not the host — the host correctly refuses to store a client-owned global, so routing it to the host is a silent no-op. `isClientBundled` is the discriminator; see `getBuiltinMcpServerEnablementActions` in `mcpListWidget.ts`.\n\n## Debugging playbook\n\nRank your signals. They disagree, and the model lies:\n\n1. **Primary** — the published customization object and the host's stored decision.\n2. **Definitive for tool exposure** — `tool_search override … clientMatched=[…]` in `Agent Host.log`.\n3. **Secondary** — the customizations UI.\n4. **Corroborating only** — what the model says. A model answered \"yes, I have azure tools\" while the server was `stopped`. Never conclude from this alone.\n\nReproduction recipe that exercises the real failure surface: start a session, send a message to boot everything, disable the thing, then ask a **new** session whether it has those tools. Cross-session persistence is where identity and overlay bugs surface.\n\nUse the `agent-host-logs` skill for exported bundles, and the `launch` skill to drive a real instance.\n\nKnown false alarms:\n\n- The `azure` plugin contributes 24 `azure-*` **skills** in addition to its MCP server. Disabling the server correctly leaves the skills enabled.\n- `sleepy` is a deliberately broken test server that cannot initialize — useless as a positive control.\n\n## Gotchas that cost real time\n\n- `CustomizationType` and `CustomizationEnablementKind` are `const enum`s. A **type-only import compiles and lints cleanly, then crashes at runtime.** Import them as values.\n- The unit-test runner uses pre-compiled output and does **not** fail on type errors. Always run `pnpm run typecheck-client` separately.\n- Integration-test servers start with `--quiet`. Wiring that you hoist out of `if (!options.quiet)` in `agentHostServerMain.ts` silently changes their behaviour — hoisting `setWorktreeIsolation` made quiet servers resolve `isolation: 'folder'` and broke seven unrelated tests.\n- Protocol files under `common\u002Fstate\u002Fprotocol\u002F` carry a \"DO NOT EDIT — auto-generated\" banner. Change the `agent-host-protocol` repo and sync with `scripts\u002Fsync-agent-host-protocol.ts` (see `common\u002Fstate\u002FAGENTS.md`), updating hand-written consumers in the same change.\n- Electron runner setup aborts (`EEXIST`\u002F`EPERM`\u002F`ENOENT`\u002FReactiveObjC) are environmental. Recover with `rm -rf .build\u002Felectron && pnpm run electron`.\n\n## Validation\n\n```sh\npnpm run typecheck-client\n.\u002Fscripts\u002Ftest.sh --grep \"customizationEnablement\"\n.\u002Fscripts\u002Ftest-integration.sh --runGlob \"**\u002FagentHost\u002F**\u002F{sessionConfig,toolApproval,codexCustomizations}.integrationTest.js\"\n.\u002Fscripts\u002Ftest-integration.sh --run src\u002Fvs\u002Fplatform\u002FagentHost\u002Ftest\u002Fnode\u002FclaudeAgent.integrationTest.ts\n```\n\nTests that construct an agent session directly need `IAgentHostCustomizationEnablementService` in their service collection; use `createNoopCustomizationEnablementService()` from `src\u002Fvs\u002Fplatform\u002FagentHost\u002Ftest\u002Fnode\u002FtestCustomizationEnablementService.ts`.\n","# Customizations in the Agent Host\n\nCustomizations are the plugins, MCP servers, agents, skills and instructions that an agent-host session exposes to a model. This skill covers **enablement**: how a customization's on\u002Foff state is decided, stored, published and enforced.\n\nRead this before changing anything in:\n\n- `src\u002Fvs\u002Fplatform\u002FagentHost\u002Fnode\u002FagentHostCustomizationEnablementService.ts`\n- `src\u002Fvs\u002Fplatform\u002FagentHost\u002Fnode\u002Fshared\u002FcustomizationEnablementGate.ts`\n- `src\u002Fvs\u002Fplatform\u002FagentHost\u002Fcommon\u002FcustomizationEnablement.ts`\n- the per-provider customization paths under `node\u002Fcopilot\u002F`, `node\u002Fclaude\u002F`, `node\u002Fcodex\u002F`\n\n## The mental model\n\n### Enablement is a list of scoped decisions, not a boolean\n\nA plugin or MCP server carries `enablement?: CustomizationEnablement[]` — an ordered list of decisions, most specific first:\n\n| Kind | Owner | Meaning |\n|---|---|---|\n| `Session` | agent host | this session only |\n| `Workspace` | agent host | this working directory (carries `uri`) |\n| `Global` | client, unless the host discovered it | everywhere |\n\n`isCustomizationEnabled()` picks the first entry; absent entries inherit from the next scope out, and an absent list means enabled. Never re-add a parallel `enabled` boolean to plugins or MCP servers — a second source of truth is what this design exists to remove. (`DirectoryCustomization` legitimately keeps a plain `enabled`; consumers derive its state through `isCustomizationEnabled()` all the same.)\n\n### Who owns `Global`\n\nThe host owns `Global` for anything it **discovered**, even when that thing lives inside a plugin the client forwarded. The client owns `Global` only for what it actually **bundled**. The discriminator is `childEnablement` — *not* `clientId`. A plugin whose `childEnablement` record has a key for a child MCP server means \"the client bundled this child and owns its global decision\"; anything else the host discovered by parsing the plugin directory.\n\n### The overlay model\n\nThis is the single most important invariant, and getting it wrong caused a self-defeating write that silently erased user decisions:\n\n> The client's value is the **base**. Host decisions layer **on top**. \"Store only what differs\" compares against that base — never against a hardcoded `true`.\n\nConcretely, in `agentHostCustomizationEnablementService.ts`:\n\n- `_clientGlobalEnablement` is the in-memory **base**, per session. `_setClientGlobal` writes here and **must never touch `_persistent`**.\n- `_persistent` holds only host-owned decisions that differ from the base.\n- Inheritance runs host → base → `DEFAULT_CUSTOMIZATION_ENABLED` (`_globalEnablement`, `_workspaceInheritedEnablement`).\n- `_setPersistentDecision` deletes a decision that matches its inherited value, so the UI can restore inheritance without a third \"Inherit\" action.\n\nKeeping these separate is what stops this loop: `replaceEnablement` → synchronous republish → client's stale `[{global,true}]` → `_setClientGlobal` → \"store only what differs\" deletes the entry just written.\n\n### Identity must not depend on tree position\n\nAn MCP server's storage key is derived from `owningPluginUri`, never from where it happened to appear in the published tree. The same server discovered top-level (`mcpServers#azure`) and nested under a plugin (`\u003CpluginURI>#mcp=azure`) must produce **one** key, or a decision written in one session is invisible to the next. `targetForMcpServer()` and `withOwningPluginUri()` in the gate are the only supported way to build that target.\n\n### Customization URIs have an author\n\nA client-published plugin's `uri` is in that client's URI space, but its `children` are host-authored paths into the host's materialized copy. Resolve them with `getAgentHostCustomizationUri` and treat other clients' plugins as opaque. A same-host plugin is published as `vscode-agent-host-file:`; match it to its client source through `id` or the decoded URI, never the raw published URI. See [Agent Host URI spaces](..\u002F..\u002Finstructions\u002Fagent-host-uri-spaces.instructions.md).\n\n### Pending means fail closed — but pending must be transient\n\n`resolve()` returns `{kind:'pending'}` when the session isn't initialized yet (`reason: 'session'`) or the working directory isn't known (`reason: 'workingDirectory'`). `resolveCustomizationEnablement()` records those in `pendingCustomizationIds`, and `isCustomizationSdkEligible()` makes SDK-boundary consumers **fail closed**.\n\nTwo rules follow:\n\n1. Never \"fix\" a pending customization by defaulting it to enabled.\n2. Never cache the pending verdict. Pending is a *temporary* state; recompute it, and republish when the enablement service settles. A cached `pendingEnablement: true` silently drops a plugin forever.\n\nA pending child MCP server also marks its **containing plugin** pending, because a plugin directory can cause the SDK to discover the child on its own.\n\n## The rule that prevents most bugs\n\n> **Every publication, emit and SDK-handoff path must go through resolution.**\n\nThree separate production bugs on this feature came from paths that skipped it (four sites in `copilotAgent`, one in `mcpCustomizationController`, plus the post-startup reconcile). When you add a new place that publishes a customization or hands one to a provider, route it through `resolveCustomizationEnablement()` — do not read a stored snapshot.\n\nThe corollary: **state computed once must be rebuilt when its inputs change.** Merged per-client enablement maps that are only appended to will leak stale decisions onto a newly parsed plugin with the same URI.\n\n## Enforcement is per-provider, and they differ\n\n| Provider | Launch | Mid-session |\n|---|---|---|\n| Copilot | `disabledMcpServers` on `SessionConfig` at open\u002Fresume | `rpc.mcp.enable` \u002F `rpc.mcp.disable` |\n| Claude | session options at materialize | live reconcile |\n| Codex | MCP servers supplied only at `thread\u002Fstart` \u002F resume | **not possible** — documented limitation |\n\nEnforcement traps:\n\n- The post-startup reconcile runs ~800 ms after launch. Anything gated *only* there can still start, and request authentication, during the launch window. Gate at launch too.\n- The SDK's `not_configured` status must **not** be translated as `enabled: true`. That bug made a correct \"skip this disabled server\" decision look like \"enable it\".\n- Copilot launch gating must include names from user `mcp.config.list`, not only the client snapshot. Reconcile and authentication also resolve newly discovered names before the host retains them; later publication must not turn an inherited enabled default into explicit intent to enable an SDK-configured-disabled server.\n- Root MCP customization IDs use the owning AHP session ID, not its SDK backing ID. On restoration, derive declared MCP names from the applied root\u002Fplugin definitions, never from the retained host-published runtime inventory.\n- Connection lifecycle (`pending`, `connected`, `stopped`) is not enablement intent. Confirm external toggles against passive `mcp.listConfigured` enablement, ignoring stale asynchronous snapshots and host-requested changes.\n\nClient-provided MCP servers (ones the client bundled rather than the host discovering) must route their global Disable to the **client**, not the host — the host correctly refuses to store a client-owned global, so routing it to the host is a silent no-op. `isClientBundled` is the discriminator; see `getBuiltinMcpServerEnablementActions` in `mcpListWidget.ts`.\n\n## Debugging playbook\n\nRank your signals. They disagree, and the model lies:\n\n1. **Primary** — the published customization object and the host's stored decision.\n2. **Definitive for tool exposure** — `tool_search override … clientMatched=[…]` in `Agent Host.log`.\n3. **Secondary** — the customizations UI.\n4. **Corroborating only** — what the model says. A model answered \"yes, I have azure tools\" while the server was `stopped`. Never conclude from this alone.\n\nReproduction recipe that exercises the real failure surface: start a session, send a message to boot everything, disable the thing, then ask a **new** session whether it has those tools. Cross-session persistence is where identity and overlay bugs surface.\n\nUse the `agent-host-logs` skill for exported bundles, and the `launch` skill to drive a real instance.\n\nKnown false alarms:\n\n- The `azure` plugin contributes 24 `azure-*` **skills** in addition to its MCP server. Disabling the server correctly leaves the skills enabled.\n- `sleepy` is a deliberately broken test server that cannot initialize — useless as a positive control.\n\n## Gotchas that cost real time\n\n- `CustomizationType` and `CustomizationEnablementKind` are `const enum`s. A **type-only import compiles and lints cleanly, then crashes at runtime.** Import them as values.\n- The unit-test runner uses pre-compiled output and does **not** fail on type errors. Always run `pnpm run typecheck-client` separately.\n- Integration-test servers start with `--quiet`. Wiring that you hoist out of `if (!options.quiet)` in `agentHostServerMain.ts` silently changes their behaviour — hoisting `setWorktreeIsolation` made quiet servers resolve `isolation: 'folder'` and broke seven unrelated tests.\n- Protocol files under `common\u002Fstate\u002Fprotocol\u002F` carry a \"DO NOT EDIT — auto-generated\" banner. Change the `agent-host-protocol` repo and sync with `scripts\u002Fsync-agent-host-protocol.ts` (see `common\u002Fstate\u002FAGENTS.md`), updating hand-written consumers in the same change.\n- Electron runner setup aborts (`EEXIST`\u002F`EPERM`\u002F`ENOENT`\u002FReactiveObjC) are environmental. Recover with `rm -rf .build\u002Felectron && pnpm run electron`.\n\n## Validation\n\n```sh\npnpm run typecheck-client\n.\u002Fscripts\u002Ftest.sh --grep \"customizationEnablement\"\n.\u002Fscripts\u002Ftest-integration.sh --runGlob \"**\u002FagentHost\u002F**\u002F{sessionConfig,toolApproval,codexCustomizations}.integrationTest.js\"\n.\u002Fscripts\u002Ftest-integration.sh --run src\u002Fvs\u002Fplatform\u002FagentHost\u002Ftest\u002Fnode\u002FclaudeAgent.integrationTest.ts\n```\n\nTests that construct an agent session directly need `IAgentHostCustomizationEnablementService` in their service collection; use `createNoopCustomizationEnablementService()` from `src\u002Fvs\u002Fplatform\u002FagentHost\u002Ftest\u002Fnode\u002FtestCustomizationEnablementService.ts`.\n",{"name":5,"description":7},"main","d2b1bf2230b505648e972e81d854743de79b65af",".github\u002Fskills\u002Fcustomizations-in-the-agent-host",43773,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode","https:\u002F\u002Fcode.visualstudio.com","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-11-11 08:47:49",{"source":8,"skillName":5,"commands":63,"prompt":73,"zipAvailable":74},[64,67,70],{"tool":65,"command":66},"npx","npx skills add microsoft\u002Fvscode --skill customizations-in-the-agent-host",{"tool":68,"command":69},"bunx","bunx skills add microsoft\u002Fvscode --skill customizations-in-the-agent-host",{"tool":71,"command":72},"pnpm","pnpm dlx skills add microsoft\u002Fvscode --skill customizations-in-the-agent-host","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fcustomizations-in-the-agent-host\u002FSKILL.md",true,[],[77,103,123,137,152,168],{"skillNo":78,"name":79,"nameZh":6,"description":80,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":81,"categories":82,"keywords":83,"publishedAt":47},"01M70H0ANBKZAVEP1NVV4K28M3","sweeper-query","Answer natural-language questions about the VS Code Sweeper's published issue index (index-\u003Cname>.json for microsoft\u002Fvscode and the enrolled family repos) — which issues are agent-ready to implement or plan, what the sweeper proposed for an assignee or area, whether the sweeper knows a report as a duplicate, the highest-value open bugs in a lane — and, for one issue, the review's full record (evidence with file citations, fix brief, proposed comment). Use ONLY when the request explicitly names the sweeper — \"sweeper\", \"vscodesweeper\", \"sweeper-query\", a sweeper verdict, record, brief or index, an agent-ready issue — or asks what \"the sweeper\" found, proposed or knows. Do NOT use for general questions about issues, duplicates, priorities or ranking that do not mention the sweeper. Read-only; discovery only.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fsweeper-query\u002FSKILL.md",[],[84,85,86,87,88,27,89,90,91,92,93,94,95,96,97,98,99,100,101,102],"sweeper query","query","sweeper","review","fix","request","which","natural-language","ranking","duplicates","ready","only","read","plan","open","Citations","brief","issues","code",{"skillNo":104,"name":105,"nameZh":6,"description":106,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":107,"categories":108,"keywords":109,"publishedAt":47},"01M699DRJS4YJCV600Q72SVVWE","update-skills","Create or update repository skills and instructions when major learnings are discovered during a session. Use when the user says \"learn!\", when a significant pattern or pitfall is identified, or when reusable domain knowledge should be captured for future sessions.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode\u002Fblob\u002Fmain\u002Fsrc\u002Fvs\u002Fsessions\u002Fskills\u002Fupdate-skills\u002FSKILL.md",[],[110,111,29,112,113,114,115,32,116,117,34,118,119,120,121,122,27],"update","update skills","pattern","domain","learnings","reusable","session","user","knowledge","repository","learn","create","sessions",{"skillNo":124,"name":125,"nameZh":6,"description":126,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":127,"categories":128,"keywords":129,"publishedAt":47},"01M699DPWHZ72B66P82EW31RNE","update-pr","Update the pull request for the current session. Use when the user wants to push new changes to an existing PR.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode\u002Fblob\u002Fmain\u002Fsrc\u002Fvs\u002Fsessions\u002Fskills\u002Fupdate-pr\u002FSKILL.md",[],[110,130,131,27,89,132,29,32,116,117,133,134,135,136],"pr","update pr","Existing","push","pull","pull request","changes",{"skillNo":138,"name":139,"nameZh":6,"description":140,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":141,"categories":142,"keywords":143,"publishedAt":47},"01M699DJMR6CE1MH5XCJZ0GFQ0","sync","Sync the current session branch with its upstream branch, or publish the current session branch to a remote. Use when the user asks to sync a branch, pull latest changes, rebase onto upstream, push current branch, publish branch, or set upstream.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode\u002Fblob\u002Fmain\u002Fsrc\u002Fvs\u002Fsessions\u002Fskills\u002Fsync\u002FSKILL.md",[],[139,144,145,133,134,146,27,136,147,148,149,150,32,116,117,151],"SET","publish","rebase","latest","with","remote","upstream","branch",{"skillNo":153,"name":154,"nameZh":6,"description":155,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":156,"categories":157,"keywords":158,"publishedAt":47},"01M699DGXHX6A2A72X57R6GGHJ","sync-upstream","Update a stale session branch by rebasing onto the latest origin. Use when the upstream has moved significantly and the session needs to catch up, resolving conflicts by preserving upstream changes and adapting session work to fit.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode\u002Fblob\u002Fmain\u002Fsrc\u002Fvs\u002Fsessions\u002Fskills\u002Fsync-upstream\u002FSKILL.md",[],[150,139,159,160,27,161,162,136,147,163,164,165,166,32,116,151,167,110],"sync upstream","fit","catch","catch up","origin","conflicts","stale","up","work",{"skillNo":169,"name":170,"nameZh":6,"description":171,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":172,"categories":173,"keywords":174,"publishedAt":47},"01M699DEXYFWDGW0BAXJ5QQ377","merge","Merge changes from the topic branch to the merge base branch. Use when the user wants to merge their session's work back to the base branch.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode\u002Fblob\u002Fmain\u002Fsrc\u002Fvs\u002Fsessions\u002Fskills\u002Fmerge\u002FSKILL.md",[],[170,116,32,167,151,117,27,175,176,136],"back","base"]