[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6999YSMPYWBE2908XR375WM":3,"skill-same:01M6999YSMPYWBE2908XR375WM":115},{"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":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":54,"ownerHtmlUrl":55,"ownerBlogUrl":56,"ownerDescription":57,"updatedAt":58,"install":59,"resources":72},"01M6999YSMPYWBE2908XR375WM","component-fixtures",null,"Use when creating or updating component fixtures for screenshot testing or their shared infrastructure, or when designing UI components to be fixture-friendly. Covers fixture file structure, theming, service setup, CSS scoping, async rendering, validation, and common pitfalls.","microsoft\u002Fvscode","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M6998NK2WED5M549DX06VBCH",195270,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fcomponent-fixtures\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"component fixtures","component","fixtures","structure","when","for","pitfalls","common pitfalls","rendering","ui components","shared","fixture","testing","scoping","common","ui","screenshot","infrastructure","components","css","2026-11-10 10:12:30",false,"---\nname: component-fixtures\ndescription: Use when creating or updating component fixtures for screenshot testing or their shared infrastructure, or when designing UI components to be fixture-friendly. Covers fixture file structure, theming, service setup, CSS scoping, async rendering, validation, and common pitfalls.\n---\n\n# Component Fixtures\n\nComponent fixtures render isolated UI components for visual screenshot testing via the component explorer. Fixtures live in `src\u002Fvs\u002Fworkbench\u002Ftest\u002Fbrowser\u002FcomponentFixtures\u002F` and are auto-discovered by the Vite dev server using the glob `src\u002F**\u002F*.fixture.ts`.\n\nUse tools `mcp_component-exp_`* to list and screenshot fixtures. If you cannot see these tools, inform the user to them on.\n\n## Running Fixtures Locally\n\n1. Start the component explorer server: run the **Component Explorer Server** task\n2. Use the `mcp_component-exp_list_fixtures` tool to see all available fixtures and their URLs\n3. Use the `mcp_component-exp_screenshot` tool to capture screenshots programmatically\n\n## File Structure\n\nEach fixture file exports a default `defineThemedFixtureGroup(...)`. The file must end with `.fixture.ts`.\n\n```\nsrc\u002Fvs\u002Fworkbench\u002Ftest\u002Fbrowser\u002FcomponentFixtures\u002F\n  fixtureUtils.ts              # Shared helpers (DO NOT import @vscode\u002Fcomponent-explorer elsewhere)\n  myComponent.fixture.ts       # Your fixture file\n```\n\n## Basic Pattern\n\n```typescript\nimport { ComponentFixtureContext, createEditorServices, defineComponentFixture, defineThemedFixtureGroup } from '.\u002FfixtureUtils.js';\n\nexport default defineThemedFixtureGroup({ path: 'myFeature\u002F' }, {\n    Default: defineComponentFixture({ render: renderMyComponent }),\n    AnotherVariant: defineComponentFixture({ render: renderMyComponent }),\n});\n\nfunction renderMyComponent({ container, disposableStore, theme }: ComponentFixtureContext): void {\n    container.style.width = '400px';\n\n    const instantiationService = createEditorServices(disposableStore, {\n        colorTheme: theme,\n        additionalServices: (reg) => {\n            \u002F\u002F Register additional services the component needs\n            reg.define(IMyService, MyServiceImpl);\n            reg.defineInstance(IMockService, mockInstance);\n        },\n    });\n\n    const widget = disposableStore.add(\n        instantiationService.createInstance(MyWidget, \u002F* constructor args *\u002F)\n    );\n    container.appendChild(widget.domNode);\n}\n```\n\nKey points:\n- **`defineThemedFixtureGroup`** automatically creates Dark and Light variants for each fixture\n- **`defineComponentFixture`** wraps your render function with theme setup, async readiness, and disposable management\n- **`createEditorServices`** provides a `TestInstantiationService` with base editor services pre-registered\n- Always register created widgets with `disposableStore.add(...)` to prevent leaks\n- Pass `colorTheme: theme` to `createEditorServices` so theme colors render correctly\n\n### File icon themes\n\nFixtures use Seti file icons by default. Select another built-in theme, or disable file icons, on the individual fixture:\n\n```typescript\ndefineComponentFixture({ fileIconTheme: 'vs-minimal', render: renderMyComponent });\ndefineComponentFixture({ fileIconTheme: 'none', render: renderMyComponent });\n```\n\nWhen the rendered component reads `IThemeService`, pass the selected theme from `ComponentFixtureContext` to `createEditorServices`:\n\n```typescript\nfunction renderMyComponent({ disposableStore, theme, fileIconTheme }: ComponentFixtureContext): void {\n\tconst instantiationService = createEditorServices(disposableStore, {\n\t\tcolorTheme: theme,\n\t\tfileIconTheme,\n\t});\n}\n```\n\n## Utilities from fixtureUtils.ts\n\n| Export | Purpose |\n|---|---|\n| `defineComponentFixture` | Creates Dark\u002FLight themed fixture variants from a render function |\n| `defineThemedFixtureGroup` | Groups multiple themed fixtures into a named fixture group |\n| `createEditorServices` | Creates `TestInstantiationService` with all base editor services |\n| `registerWorkbenchServices` | Registers additional workbench services (context menu, label, etc.) |\n| `createTextModel` | Creates a text model via `ModelService` for editor fixtures |\n| `setupTheme` | Applies theme CSS to a container (called automatically by `defineComponentFixture`) |\n| `darkTheme` \u002F `lightTheme` | Pre-loaded `ColorThemeData` instances |\n\n**Important:** Only `fixtureUtils.ts` may import from `@vscode\u002Fcomponent-explorer`. All fixture files must go through the helpers in `fixtureUtils.ts`.\n\n## CSS Scoping\n\nFixtures share the document and workbench stylesheets (`isolation: 'none'`). The helpers scope theme and file-icon styles, but DOM, CSS, and process-wide registrations are not isolated automatically.\n\n### Shared theme initialization\n\n`fixtureUtilsCss.ts` loads the shared workbench color and size registrations before generating and caching theme CSS, including the agent tokens in `vs\u002Fworkbench\u002Fcommon\u002FagentsColors.ts` and `agentsSizes.ts`. Keep required product-wide registrations in this shared bootstrap, not in individual fixtures: discovering another fixture must not change an existing fixture's typography or colors. Reuse lightweight registration modules from the owning shared layer rather than importing product entry points or higher-layer contributions.\n\n### Matching production CSS selectors\n\nMany VS Code components have CSS rules scoped to deep ancestor selectors (e.g., `.interactive-session .interactive-input-part > .widget-container .my-element`). In fixtures, you must recreate the required ancestor DOM structure for these selectors to match:\n\n```typescript\nfunction render({ container }: ComponentFixtureContext): void {\n    container.classList.add('interactive-session');\n\n    \u002F\u002F Recreate ancestor structure that CSS selectors expect\n    const inputPart = dom.$('.interactive-input-part');\n    const widgetContainer = dom.$('.widget-container');\n    inputPart.appendChild(widgetContainer);\n    container.appendChild(inputPart);\n\n    widgetContainer.appendChild(myWidget.domNode);\n}\n```\n\n**Design recommendation for new components:** Avoid deeply nested CSS selectors that require specific ancestor elements. Use self-contained class names (e.g., `.my-widget .my-element` rather than `.parent-view .parent-part > .wrapper .my-element`). This makes components easier to fixture and reuse.\n\n## Services\n\n### Using createEditorServices\n\n`createEditorServices` pre-registers these services: `IAccessibilityService`, `IKeybindingService`, `IClipboardService`, `IOpenerService`, `INotificationService`, `IDialogService`, `IUndoRedoService`, `ILanguageService`, `IConfigurationService`, `IStorageService`, `IThemeService`, `IModelService`, `ICodeEditorService`, `IContextKeyService`, `ICommandService`, `ITelemetryService`, `IHoverService`, `IUserInteractionService`, and more.\n\n### Additional services\n\nRegister extra services via `additionalServices`:\n\n```typescript\ncreateEditorServices(disposableStore, {\n    additionalServices: (reg) => {\n        \u002F\u002F Class-based (instantiated by DI):\n        reg.define(IMyService, MyServiceImpl);\n        \u002F\u002F Instance-based (pre-constructed):\n        reg.defineInstance(IMyService, myMockInstance);\n    },\n});\n```\n\n### Mocking services\n\nUse the `mock\u003CT>()` helper from `base\u002Ftest\u002Fcommon\u002Fmock.js` to create mock service instances:\n\n```typescript\nimport { mock } from '..\u002F..\u002F..\u002F..\u002Fbase\u002Ftest\u002Fcommon\u002Fmock.js';\n\nconst myService = new class extends mock\u003CIMyService>() {\n    override someMethod(): string { return 'test'; }\n    override onSomeEvent = Event.None;\n};\nreg.defineInstance(IMyService, myService);\n```\n\nFor mock view models or data objects:\n```typescript\nconst element = new class extends mock\u003CIChatRequestViewModel>() { }();\n```\n\n## Async Rendering\n\nThe component explorer awaits the render promise, then waits two animation frames. Those frames are not a readiness guarantee for image decoding, native resize observers, or delayed layout.\n\nThe render promise must resolve only when the fixture represents its named state:\n\n- Await assets that affect the screenshot. An editor's `setInput()` may return before its main image or thumbnails have loaded; wait for the expected image count and await `decode()`, failing on missing or broken images.\n- Finish layout-changing actions before positioning the viewport. Wait for content height, scroll height, scroll position, and finite animations to settle, then scroll and settle again. Assert that an \"offscreen\" header is actually offscreen and a \"visible\" header is not covered by sticky content.\n- Account for transient visuals. A stable height does not mean a stable screenshot. Headless renders never flash auto-hiding scrollbars on scroll or resize, so do not wait for or hide them; use `ScrollbarVisibility.Visible` when a scrollbar is part of the intended state.\n- Supply deterministic display data through existing services\u002Foptions, such as a single custom thinking phrase. A seeded random generator alone does not make labels independent of render order or async callback order.\n- Use bounded, condition-based waits that throw on failure, not fixed sleeps or extra frames that silently accept an incomplete state.\n\nDesign fixtures as **state + local inputs + an explicit readiness condition**. Supply local account icons instead of letting a mock fall back to a live avatar URL, and await decoding; `waitForFixtureCondition` polls native browser frames while preserving the virtual clock. To wait for DOM state, such as an element, class, attribute or text appearing, use `waitForFixtureDomCondition`, which re-checks the condition after each DOM mutation; a condition that never holds fails at the explorer's fixture timeout. Prefer shared DOM spinners over animated SVG backgrounds: ancestor CSS cannot stop animations inside an image.\n\nFixtures that depend on native browser image decoding or resize\u002Fscroll callbacks can use `virtualTime: { enabled: false }` and explicitly await those operations. Virtual JavaScript time does not advance the browser's image decoder or layout pipeline.\n\nFor async fixtures with paint-order-sensitive edges, `deferPaint: true` keeps the headless fixture transparent until rendering has finished, without changing its layout or interactive preview. It prevents intermediate paints from affecting the final rasterization; it does **not** replace awaiting readiness.\n\n### Validating fixtures\n\nDo not add automated tests whose subject is fixtures or fixture infrastructure (including fixture-only unit, Playwright, and screenshot-stability tests). Validate fixture changes with the existing Component Explorer rendering, screenshot, stability, and error tools, plus direct inspection or temporary browser probes. Ordinary tests for production behavior belong at the owning production API.\n\nValidate at the same readiness boundary CI uses: capture immediately after the headless `renderFixture()` resolves, after idle callbacks, and after remounting following another fixture. Compare exact hashes on the same platform and separately inspect the intended state; do not commit the temporary probes as fixture tests.\n\n### Pitfall: DOM reparenting causes flickering\n\nAvoid moving rendered widgets between DOM parents after initial render. This causes:\n- Layout recalculation (the widget jumps as `position: absolute` coordinates become invalid)\n- Focus loss (blur events can trigger hide logic in widgets like QuickInput)\n- Screenshot instability (the component explorer may capture an intermediate layout state)\n\n**Bad pattern — reparenting a widget after async wait:**\n```typescript\nasync function render({ container }: ComponentFixtureContext): Promise\u003Cvoid> {\n    const host = document.createElement('div');\n    container.appendChild(host);\n    \u002F\u002F ... create widget inside host ...\n    await waitForWidget();\n    container.appendChild(widget);  \u002F\u002F BAD: reparenting causes flicker\n    host.remove();\n}\n```\n\n**Better pattern — render in-place with the correct DOM structure from the start:**\n```typescript\nfunction render({ container }: ComponentFixtureContext): void {\n    \u002F\u002F Set up the correct DOM structure first, then create the widget inside it\n    const widget = createWidget(container);\n    container.appendChild(widget.domNode);\n}\n```\n\nIf the component absolutely requires async setup (e.g., QuickInput which renders internally), minimize DOM manipulation after the widget appears by structuring the host container to match the final layout from the beginning.\n\n## Adapting Existing Components for Fixtures\n\nExisting components often need small changes to become fixturable. When writing a fixture reveals friction, fix the component — don't work around it in the fixture. Common adaptations:\n\n### Decouple CSS from ancestor context\n\nIf a component's CSS only works inside a deeply nested selector like `.workbench .sidebar .my-view .my-widget`, refactor the CSS to be self-contained. Move the styles so they're scoped to the component's own root class:\n\n```css\n\u002F* Before: requires specific ancestors *\u002F\n.workbench .sidebar .my-view .my-widget .header { font-weight: bold; }\n\n\u002F* After: self-contained *\u002F\n.my-widget .header { font-weight: bold; }\n```\n\nIf the component shares styles with its parent (e.g., inheriting background color), use CSS custom properties rather than relying on ancestor selectors.\n\n### Extract hard-coded service dependencies\n\nIf a component reaches into singletons or global state instead of using DI, refactor it to accept services through the constructor:\n\n```typescript\n\u002F\u002F Before: hard to mock in fixtures\nclass MyWidget {\n    private readonly config = getSomeGlobalConfig();\n}\n\n\u002F\u002F After: injectable and testable\nclass MyWidget {\n    constructor(@IConfigurationService private readonly configService: IConfigurationService) { }\n}\n```\n\n### Add options to control auto-focus and animation\n\nComponents that auto-focus on creation or run animations cause flaky screenshots. Add an options parameter:\n\n```typescript\ninterface IMyWidgetOptions {\n    shouldAutoFocus?: boolean;\n}\n```\n\nThe fixture passes `shouldAutoFocus: false`. The production call site keeps the default behavior.\n\n### Expose internal state for \"already completed\" rendering\n\nMany components have lifecycle states (loading → active → completed). If the component can only reach the \"completed\" state through user interaction, add support for initializing directly into that state via constructor data:\n\n```typescript\n\u002F\u002F The fixture can pass pre-filled data to render the summary\u002Fcompleted state\n\u002F\u002F without simulating the full user interaction flow.\nconst carousel: IChatQuestionCarousel = {\n    questions,\n    allowSkip: true,\n    kind: 'questionCarousel',\n    isUsed: true,           \u002F\u002F Already completed\n    data: { 'q1': 'answer' }, \u002F\u002F Pre-filled answers\n};\n```\n\n### Make DOM node accessible\n\nIf a component builds its DOM internally and doesn't expose the root element, add a public `readonly domNode: HTMLElement` property so fixtures can append it to the container.\n\n### Keep test-only operations out of the production API\n\nWhen a fixture or test must drive state that production reaches only through user input or services (for example focusing, selecting, or collapsing rows, or locating a rendered row), don't add public methods for it: other code will start calling them and bypass the real flows. Make the minimum `protected` and implement the operations in a test-only subclass under `test\u002F` (such as `TestSessionsList extends SessionsList`), which product code cannot import.\n\n## Writing Fixture-Friendly Components\n\nWhen designing new UI components, follow these practices to make them easy to fixture:\n\n### 1. Accept a container element in the constructor\n\n```typescript\n\u002F\u002F Good: container is passed in\nclass MyWidget {\n    constructor(container: HTMLElement, @IFoo foo: IFoo) {\n        this.domNode = dom.append(container, dom.$('.my-widget'));\n    }\n}\n\n\u002F\u002F Also good: widget creates its own domNode for the caller to place\nclass MyWidget {\n    readonly domNode: HTMLElement;\n    constructor(@IFoo foo: IFoo) {\n        this.domNode = dom.$('.my-widget');\n    }\n}\n```\n\n### 2. Use dependency injection for all services\n\nAll external dependencies should come through DI so fixtures can provide test implementations:\n\n```typescript\n\u002F\u002F Good: services injected\nconstructor(@IThemeService private readonly themeService: IThemeService) { }\n\n\u002F\u002F Bad: reaching into globals\nconstructor() { this.theme = getGlobalTheme(); }\n```\n\n### 3. Keep CSS selectors shallow\n\n```css\n\u002F* Good: self-contained, easy to fixture *\u002F\n.my-widget .my-header { ... }\n.my-widget .my-list-item { ... }\n\n\u002F* Bad: requires deep ancestor chain *\u002F\n.workbench .sidebar .my-view .my-widget .my-header { ... }\n```\n\n### 4. Avoid reading from layout\u002Fwindow services during construction\n\nComponents that measure the window or read layout dimensions during construction are hard to fixture because the shadow DOM container has different dimensions than the workbench:\n\n```typescript\n\u002F\u002F Prefer: use CSS for sizing, or accept dimensions as parameters\ncontainer.style.width = '400px';\ncontainer.style.height = '300px';\n\n\u002F\u002F Avoid: reading from layoutService during construction\nconst width = this.layoutService.mainContainerDimension.width;\n```\n\n### 5. Support disabling auto-focus in fixtures\n\nAuto-focus can interfere with screenshot stability. Provide options to disable it:\n\n```typescript\ninterface IMyWidgetOptions {\n    shouldAutoFocus?: boolean;  \u002F\u002F Fixtures pass false\n}\n```\n\n### 6. Expose the DOM node\n\nThe fixture needs to append the widget's DOM to the container. Expose it as a public `readonly domNode: HTMLElement`.\n\n### 7. Make hover and focus states renderable\n\nFixtures cannot trigger CSS `:hover`, and DOM focus is only deterministic through `ctx.focus()`. Keep interaction-dependent visuals reachable from state:\n\n- Pair every `:hover` selector a visual depends on with a `.hovered` class, e.g. `.monaco-list-row:is(:hover, .hovered)`; `:is()` keeps specificity unchanged. List widgets already style `.monaco-list-row.hovered` like a hovered row.\n- Drive focus and selection through the component (list rows get `.focused` and `.selected` from the list traits), from a test-only subclass when production has no such API (see [Keep test-only operations out of the production API](#keep-test-only-operations-out-of-the-production-api)). Then call `ctx.focus()` when the state needs DOM focus.\n- When JavaScript also reacts to hover (for example `mouseover` listeners), dispatch a `mouseover` on the element as well as adding `.hovered`.\n\n`src\u002Fvs\u002Fsessions\u002Fcontrib\u002Fsessions\u002Ftest\u002Fbrowser\u002FsessionsListFixtureUtils.ts` renders `interaction: { hovered, focused, selected }` this way.\n\n## Multiple Fixture Variants\n\nCreate variants to show different states of the same component:\n\n```typescript\nexport default defineThemedFixtureGroup({\n    \u002F\u002F Different data states\n    Empty: defineComponentFixture({ render: (ctx) => renderWidget(ctx, { items: [] }) }),\n    WithItems: defineComponentFixture({ render: (ctx) => renderWidget(ctx, { items: sampleItems }) }),\n\n    \u002F\u002F Different configurations\n    ReadOnly: defineComponentFixture({ render: (ctx) => renderWidget(ctx, { readonly: true }) }),\n    Editable: defineComponentFixture({ render: (ctx) => renderWidget(ctx, { readonly: false }) }),\n\n    \u002F\u002F Lifecycle states\n    Loading: defineComponentFixture({ render: (ctx) => renderWidget(ctx, { state: 'loading' }) }),\n    Completed: defineComponentFixture({ render: (ctx) => renderWidget(ctx, { state: 'done' }) }),\n});\n```\n\n## Learnings\n\nUpdate this section with insights from your fixture development experience!\n\n* Do not copy the component to the fixture and modify it there. Always adapt the original component to be fixture-friendly, then render it in the fixture. This ensures the fixture tests the real component code and lifecycle, rather than a modified version that may hide bugs.\n\n* **Don't recompose child widgets in fixtures.** Never manually instantiate and add a sub-widget (e.g., a toolbar content widget) that the parent component is supposed to create. Instead, configure the parent correctly (e.g., set the right editor option, register the right provider) so the child appears through the normal code path. Manually recomposing hides integration bugs and doesn't test the real widget lifecycle.\n\n* **Describe state as data for service-heavy components.** When a component reads many services, give it one harness that takes plain state and renders it through the real state-owning services and production menus, instead of per-fixture mocks and DOM hacks. Fixtures then only list data, and a new feature adds a state field to the harness. The sessions list harness (`sessionsListFixtureUtils.ts`) follows this pattern; its real toolbars exposed header bugs that stubbed menus had hidden.\n\n* **Never vary process-wide registrations per fixture.** The explorer UI mounts all fixtures of a folder at once, and they share command, menu, and other global registries. Register shared actions once, the same for every fixture, and vary per-fixture presentation through the fixture's own services, such as its menu service. Screenshot runs render fixtures one at a time and don't catch mount-order races, so preview the whole folder (`___explorer?fixture=\u003Cfolder>`) to check.\n","# Component Fixtures\n\nComponent fixtures render isolated UI components for visual screenshot testing via the component explorer. Fixtures live in `src\u002Fvs\u002Fworkbench\u002Ftest\u002Fbrowser\u002FcomponentFixtures\u002F` and are auto-discovered by the Vite dev server using the glob `src\u002F**\u002F*.fixture.ts`.\n\nUse tools `mcp_component-exp_`* to list and screenshot fixtures. If you cannot see these tools, inform the user to them on.\n\n## Running Fixtures Locally\n\n1. Start the component explorer server: run the **Component Explorer Server** task\n2. Use the `mcp_component-exp_list_fixtures` tool to see all available fixtures and their URLs\n3. Use the `mcp_component-exp_screenshot` tool to capture screenshots programmatically\n\n## File Structure\n\nEach fixture file exports a default `defineThemedFixtureGroup(...)`. The file must end with `.fixture.ts`.\n\n```\nsrc\u002Fvs\u002Fworkbench\u002Ftest\u002Fbrowser\u002FcomponentFixtures\u002F\n  fixtureUtils.ts              # Shared helpers (DO NOT import @vscode\u002Fcomponent-explorer elsewhere)\n  myComponent.fixture.ts       # Your fixture file\n```\n\n## Basic Pattern\n\n```typescript\nimport { ComponentFixtureContext, createEditorServices, defineComponentFixture, defineThemedFixtureGroup } from '.\u002FfixtureUtils.js';\n\nexport default defineThemedFixtureGroup({ path: 'myFeature\u002F' }, {\n    Default: defineComponentFixture({ render: renderMyComponent }),\n    AnotherVariant: defineComponentFixture({ render: renderMyComponent }),\n});\n\nfunction renderMyComponent({ container, disposableStore, theme }: ComponentFixtureContext): void {\n    container.style.width = '400px';\n\n    const instantiationService = createEditorServices(disposableStore, {\n        colorTheme: theme,\n        additionalServices: (reg) => {\n            \u002F\u002F Register additional services the component needs\n            reg.define(IMyService, MyServiceImpl);\n            reg.defineInstance(IMockService, mockInstance);\n        },\n    });\n\n    const widget = disposableStore.add(\n        instantiationService.createInstance(MyWidget, \u002F* constructor args *\u002F)\n    );\n    container.appendChild(widget.domNode);\n}\n```\n\nKey points:\n- **`defineThemedFixtureGroup`** automatically creates Dark and Light variants for each fixture\n- **`defineComponentFixture`** wraps your render function with theme setup, async readiness, and disposable management\n- **`createEditorServices`** provides a `TestInstantiationService` with base editor services pre-registered\n- Always register created widgets with `disposableStore.add(...)` to prevent leaks\n- Pass `colorTheme: theme` to `createEditorServices` so theme colors render correctly\n\n### File icon themes\n\nFixtures use Seti file icons by default. Select another built-in theme, or disable file icons, on the individual fixture:\n\n```typescript\ndefineComponentFixture({ fileIconTheme: 'vs-minimal', render: renderMyComponent });\ndefineComponentFixture({ fileIconTheme: 'none', render: renderMyComponent });\n```\n\nWhen the rendered component reads `IThemeService`, pass the selected theme from `ComponentFixtureContext` to `createEditorServices`:\n\n```typescript\nfunction renderMyComponent({ disposableStore, theme, fileIconTheme }: ComponentFixtureContext): void {\n\tconst instantiationService = createEditorServices(disposableStore, {\n\t\tcolorTheme: theme,\n\t\tfileIconTheme,\n\t});\n}\n```\n\n## Utilities from fixtureUtils.ts\n\n| Export | Purpose |\n|---|---|\n| `defineComponentFixture` | Creates Dark\u002FLight themed fixture variants from a render function |\n| `defineThemedFixtureGroup` | Groups multiple themed fixtures into a named fixture group |\n| `createEditorServices` | Creates `TestInstantiationService` with all base editor services |\n| `registerWorkbenchServices` | Registers additional workbench services (context menu, label, etc.) |\n| `createTextModel` | Creates a text model via `ModelService` for editor fixtures |\n| `setupTheme` | Applies theme CSS to a container (called automatically by `defineComponentFixture`) |\n| `darkTheme` \u002F `lightTheme` | Pre-loaded `ColorThemeData` instances |\n\n**Important:** Only `fixtureUtils.ts` may import from `@vscode\u002Fcomponent-explorer`. All fixture files must go through the helpers in `fixtureUtils.ts`.\n\n## CSS Scoping\n\nFixtures share the document and workbench stylesheets (`isolation: 'none'`). The helpers scope theme and file-icon styles, but DOM, CSS, and process-wide registrations are not isolated automatically.\n\n### Shared theme initialization\n\n`fixtureUtilsCss.ts` loads the shared workbench color and size registrations before generating and caching theme CSS, including the agent tokens in `vs\u002Fworkbench\u002Fcommon\u002FagentsColors.ts` and `agentsSizes.ts`. Keep required product-wide registrations in this shared bootstrap, not in individual fixtures: discovering another fixture must not change an existing fixture's typography or colors. Reuse lightweight registration modules from the owning shared layer rather than importing product entry points or higher-layer contributions.\n\n### Matching production CSS selectors\n\nMany VS Code components have CSS rules scoped to deep ancestor selectors (e.g., `.interactive-session .interactive-input-part > .widget-container .my-element`). In fixtures, you must recreate the required ancestor DOM structure for these selectors to match:\n\n```typescript\nfunction render({ container }: ComponentFixtureContext): void {\n    container.classList.add('interactive-session');\n\n    \u002F\u002F Recreate ancestor structure that CSS selectors expect\n    const inputPart = dom.$('.interactive-input-part');\n    const widgetContainer = dom.$('.widget-container');\n    inputPart.appendChild(widgetContainer);\n    container.appendChild(inputPart);\n\n    widgetContainer.appendChild(myWidget.domNode);\n}\n```\n\n**Design recommendation for new components:** Avoid deeply nested CSS selectors that require specific ancestor elements. Use self-contained class names (e.g., `.my-widget .my-element` rather than `.parent-view .parent-part > .wrapper .my-element`). This makes components easier to fixture and reuse.\n\n## Services\n\n### Using createEditorServices\n\n`createEditorServices` pre-registers these services: `IAccessibilityService`, `IKeybindingService`, `IClipboardService`, `IOpenerService`, `INotificationService`, `IDialogService`, `IUndoRedoService`, `ILanguageService`, `IConfigurationService`, `IStorageService`, `IThemeService`, `IModelService`, `ICodeEditorService`, `IContextKeyService`, `ICommandService`, `ITelemetryService`, `IHoverService`, `IUserInteractionService`, and more.\n\n### Additional services\n\nRegister extra services via `additionalServices`:\n\n```typescript\ncreateEditorServices(disposableStore, {\n    additionalServices: (reg) => {\n        \u002F\u002F Class-based (instantiated by DI):\n        reg.define(IMyService, MyServiceImpl);\n        \u002F\u002F Instance-based (pre-constructed):\n        reg.defineInstance(IMyService, myMockInstance);\n    },\n});\n```\n\n### Mocking services\n\nUse the `mock\u003CT>()` helper from `base\u002Ftest\u002Fcommon\u002Fmock.js` to create mock service instances:\n\n```typescript\nimport { mock } from '..\u002F..\u002F..\u002F..\u002Fbase\u002Ftest\u002Fcommon\u002Fmock.js';\n\nconst myService = new class extends mock\u003CIMyService>() {\n    override someMethod(): string { return 'test'; }\n    override onSomeEvent = Event.None;\n};\nreg.defineInstance(IMyService, myService);\n```\n\nFor mock view models or data objects:\n```typescript\nconst element = new class extends mock\u003CIChatRequestViewModel>() { }();\n```\n\n## Async Rendering\n\nThe component explorer awaits the render promise, then waits two animation frames. Those frames are not a readiness guarantee for image decoding, native resize observers, or delayed layout.\n\nThe render promise must resolve only when the fixture represents its named state:\n\n- Await assets that affect the screenshot. An editor's `setInput()` may return before its main image or thumbnails have loaded; wait for the expected image count and await `decode()`, failing on missing or broken images.\n- Finish layout-changing actions before positioning the viewport. Wait for content height, scroll height, scroll position, and finite animations to settle, then scroll and settle again. Assert that an \"offscreen\" header is actually offscreen and a \"visible\" header is not covered by sticky content.\n- Account for transient visuals. A stable height does not mean a stable screenshot. Headless renders never flash auto-hiding scrollbars on scroll or resize, so do not wait for or hide them; use `ScrollbarVisibility.Visible` when a scrollbar is part of the intended state.\n- Supply deterministic display data through existing services\u002Foptions, such as a single custom thinking phrase. A seeded random generator alone does not make labels independent of render order or async callback order.\n- Use bounded, condition-based waits that throw on failure, not fixed sleeps or extra frames that silently accept an incomplete state.\n\nDesign fixtures as **state + local inputs + an explicit readiness condition**. Supply local account icons instead of letting a mock fall back to a live avatar URL, and await decoding; `waitForFixtureCondition` polls native browser frames while preserving the virtual clock. To wait for DOM state, such as an element, class, attribute or text appearing, use `waitForFixtureDomCondition`, which re-checks the condition after each DOM mutation; a condition that never holds fails at the explorer's fixture timeout. Prefer shared DOM spinners over animated SVG backgrounds: ancestor CSS cannot stop animations inside an image.\n\nFixtures that depend on native browser image decoding or resize\u002Fscroll callbacks can use `virtualTime: { enabled: false }` and explicitly await those operations. Virtual JavaScript time does not advance the browser's image decoder or layout pipeline.\n\nFor async fixtures with paint-order-sensitive edges, `deferPaint: true` keeps the headless fixture transparent until rendering has finished, without changing its layout or interactive preview. It prevents intermediate paints from affecting the final rasterization; it does **not** replace awaiting readiness.\n\n### Validating fixtures\n\nDo not add automated tests whose subject is fixtures or fixture infrastructure (including fixture-only unit, Playwright, and screenshot-stability tests). Validate fixture changes with the existing Component Explorer rendering, screenshot, stability, and error tools, plus direct inspection or temporary browser probes. Ordinary tests for production behavior belong at the owning production API.\n\nValidate at the same readiness boundary CI uses: capture immediately after the headless `renderFixture()` resolves, after idle callbacks, and after remounting following another fixture. Compare exact hashes on the same platform and separately inspect the intended state; do not commit the temporary probes as fixture tests.\n\n### Pitfall: DOM reparenting causes flickering\n\nAvoid moving rendered widgets between DOM parents after initial render. This causes:\n- Layout recalculation (the widget jumps as `position: absolute` coordinates become invalid)\n- Focus loss (blur events can trigger hide logic in widgets like QuickInput)\n- Screenshot instability (the component explorer may capture an intermediate layout state)\n\n**Bad pattern — reparenting a widget after async wait:**\n```typescript\nasync function render({ container }: ComponentFixtureContext): Promise\u003Cvoid> {\n    const host = document.createElement('div');\n    container.appendChild(host);\n    \u002F\u002F ... create widget inside host ...\n    await waitForWidget();\n    container.appendChild(widget);  \u002F\u002F BAD: reparenting causes flicker\n    host.remove();\n}\n```\n\n**Better pattern — render in-place with the correct DOM structure from the start:**\n```typescript\nfunction render({ container }: ComponentFixtureContext): void {\n    \u002F\u002F Set up the correct DOM structure first, then create the widget inside it\n    const widget = createWidget(container);\n    container.appendChild(widget.domNode);\n}\n```\n\nIf the component absolutely requires async setup (e.g., QuickInput which renders internally), minimize DOM manipulation after the widget appears by structuring the host container to match the final layout from the beginning.\n\n## Adapting Existing Components for Fixtures\n\nExisting components often need small changes to become fixturable. When writing a fixture reveals friction, fix the component — don't work around it in the fixture. Common adaptations:\n\n### Decouple CSS from ancestor context\n\nIf a component's CSS only works inside a deeply nested selector like `.workbench .sidebar .my-view .my-widget`, refactor the CSS to be self-contained. Move the styles so they're scoped to the component's own root class:\n\n```css\n\u002F* Before: requires specific ancestors *\u002F\n.workbench .sidebar .my-view .my-widget .header { font-weight: bold; }\n\n\u002F* After: self-contained *\u002F\n.my-widget .header { font-weight: bold; }\n```\n\nIf the component shares styles with its parent (e.g., inheriting background color), use CSS custom properties rather than relying on ancestor selectors.\n\n### Extract hard-coded service dependencies\n\nIf a component reaches into singletons or global state instead of using DI, refactor it to accept services through the constructor:\n\n```typescript\n\u002F\u002F Before: hard to mock in fixtures\nclass MyWidget {\n    private readonly config = getSomeGlobalConfig();\n}\n\n\u002F\u002F After: injectable and testable\nclass MyWidget {\n    constructor(@IConfigurationService private readonly configService: IConfigurationService) { }\n}\n```\n\n### Add options to control auto-focus and animation\n\nComponents that auto-focus on creation or run animations cause flaky screenshots. Add an options parameter:\n\n```typescript\ninterface IMyWidgetOptions {\n    shouldAutoFocus?: boolean;\n}\n```\n\nThe fixture passes `shouldAutoFocus: false`. The production call site keeps the default behavior.\n\n### Expose internal state for \"already completed\" rendering\n\nMany components have lifecycle states (loading → active → completed). If the component can only reach the \"completed\" state through user interaction, add support for initializing directly into that state via constructor data:\n\n```typescript\n\u002F\u002F The fixture can pass pre-filled data to render the summary\u002Fcompleted state\n\u002F\u002F without simulating the full user interaction flow.\nconst carousel: IChatQuestionCarousel = {\n    questions,\n    allowSkip: true,\n    kind: 'questionCarousel',\n    isUsed: true,           \u002F\u002F Already completed\n    data: { 'q1': 'answer' }, \u002F\u002F Pre-filled answers\n};\n```\n\n### Make DOM node accessible\n\nIf a component builds its DOM internally and doesn't expose the root element, add a public `readonly domNode: HTMLElement` property so fixtures can append it to the container.\n\n### Keep test-only operations out of the production API\n\nWhen a fixture or test must drive state that production reaches only through user input or services (for example focusing, selecting, or collapsing rows, or locating a rendered row), don't add public methods for it: other code will start calling them and bypass the real flows. Make the minimum `protected` and implement the operations in a test-only subclass under `test\u002F` (such as `TestSessionsList extends SessionsList`), which product code cannot import.\n\n## Writing Fixture-Friendly Components\n\nWhen designing new UI components, follow these practices to make them easy to fixture:\n\n### 1. Accept a container element in the constructor\n\n```typescript\n\u002F\u002F Good: container is passed in\nclass MyWidget {\n    constructor(container: HTMLElement, @IFoo foo: IFoo) {\n        this.domNode = dom.append(container, dom.$('.my-widget'));\n    }\n}\n\n\u002F\u002F Also good: widget creates its own domNode for the caller to place\nclass MyWidget {\n    readonly domNode: HTMLElement;\n    constructor(@IFoo foo: IFoo) {\n        this.domNode = dom.$('.my-widget');\n    }\n}\n```\n\n### 2. Use dependency injection for all services\n\nAll external dependencies should come through DI so fixtures can provide test implementations:\n\n```typescript\n\u002F\u002F Good: services injected\nconstructor(@IThemeService private readonly themeService: IThemeService) { }\n\n\u002F\u002F Bad: reaching into globals\nconstructor() { this.theme = getGlobalTheme(); }\n```\n\n### 3. Keep CSS selectors shallow\n\n```css\n\u002F* Good: self-contained, easy to fixture *\u002F\n.my-widget .my-header { ... }\n.my-widget .my-list-item { ... }\n\n\u002F* Bad: requires deep ancestor chain *\u002F\n.workbench .sidebar .my-view .my-widget .my-header { ... }\n```\n\n### 4. Avoid reading from layout\u002Fwindow services during construction\n\nComponents that measure the window or read layout dimensions during construction are hard to fixture because the shadow DOM container has different dimensions than the workbench:\n\n```typescript\n\u002F\u002F Prefer: use CSS for sizing, or accept dimensions as parameters\ncontainer.style.width = '400px';\ncontainer.style.height = '300px';\n\n\u002F\u002F Avoid: reading from layoutService during construction\nconst width = this.layoutService.mainContainerDimension.width;\n```\n\n### 5. Support disabling auto-focus in fixtures\n\nAuto-focus can interfere with screenshot stability. Provide options to disable it:\n\n```typescript\ninterface IMyWidgetOptions {\n    shouldAutoFocus?: boolean;  \u002F\u002F Fixtures pass false\n}\n```\n\n### 6. Expose the DOM node\n\nThe fixture needs to append the widget's DOM to the container. Expose it as a public `readonly domNode: HTMLElement`.\n\n### 7. Make hover and focus states renderable\n\nFixtures cannot trigger CSS `:hover`, and DOM focus is only deterministic through `ctx.focus()`. Keep interaction-dependent visuals reachable from state:\n\n- Pair every `:hover` selector a visual depends on with a `.hovered` class, e.g. `.monaco-list-row:is(:hover, .hovered)`; `:is()` keeps specificity unchanged. List widgets already style `.monaco-list-row.hovered` like a hovered row.\n- Drive focus and selection through the component (list rows get `.focused` and `.selected` from the list traits), from a test-only subclass when production has no such API (see [Keep test-only operations out of the production API](#keep-test-only-operations-out-of-the-production-api)). Then call `ctx.focus()` when the state needs DOM focus.\n- When JavaScript also reacts to hover (for example `mouseover` listeners), dispatch a `mouseover` on the element as well as adding `.hovered`.\n\n`src\u002Fvs\u002Fsessions\u002Fcontrib\u002Fsessions\u002Ftest\u002Fbrowser\u002FsessionsListFixtureUtils.ts` renders `interaction: { hovered, focused, selected }` this way.\n\n## Multiple Fixture Variants\n\nCreate variants to show different states of the same component:\n\n```typescript\nexport default defineThemedFixtureGroup({\n    \u002F\u002F Different data states\n    Empty: defineComponentFixture({ render: (ctx) => renderWidget(ctx, { items: [] }) }),\n    WithItems: defineComponentFixture({ render: (ctx) => renderWidget(ctx, { items: sampleItems }) }),\n\n    \u002F\u002F Different configurations\n    ReadOnly: defineComponentFixture({ render: (ctx) => renderWidget(ctx, { readonly: true }) }),\n    Editable: defineComponentFixture({ render: (ctx) => renderWidget(ctx, { readonly: false }) }),\n\n    \u002F\u002F Lifecycle states\n    Loading: defineComponentFixture({ render: (ctx) => renderWidget(ctx, { state: 'loading' }) }),\n    Completed: defineComponentFixture({ render: (ctx) => renderWidget(ctx, { state: 'done' }) }),\n});\n```\n\n## Learnings\n\nUpdate this section with insights from your fixture development experience!\n\n* Do not copy the component to the fixture and modify it there. Always adapt the original component to be fixture-friendly, then render it in the fixture. This ensures the fixture tests the real component code and lifecycle, rather than a modified version that may hide bugs.\n\n* **Don't recompose child widgets in fixtures.** Never manually instantiate and add a sub-widget (e.g., a toolbar content widget) that the parent component is supposed to create. Instead, configure the parent correctly (e.g., set the right editor option, register the right provider) so the child appears through the normal code path. Manually recomposing hides integration bugs and doesn't test the real widget lifecycle.\n\n* **Describe state as data for service-heavy components.** When a component reads many services, give it one harness that takes plain state and renders it through the real state-owning services and production menus, instead of per-fixture mocks and DOM hacks. Fixtures then only list data, and a new feature adds a state field to the harness. The sessions list harness (`sessionsListFixtureUtils.ts`) follows this pattern; its real toolbars exposed header bugs that stubbed menus had hidden.\n\n* **Never vary process-wide registrations per fixture.** The explorer UI mounts all fixtures of a folder at once, and they share command, menu, and other global registries. Register shared actions once, the same for every fixture, and vary per-fixture presentation through the fixture's own services, such as its menu service. Screenshot runs render fixtures one at a time and don't catch mount-order races, so preview the whole folder (`___explorer?fixture=\u003Cfolder>`) to check.\n",{"name":5,"description":7},"main","11ba54a90a0ff8720cf47c086f5a9948eef9cf2c",".github\u002Fskills\u002Fcomponent-fixtures",43791,"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-12 03:13:10",{"source":8,"skillName":5,"commands":60,"prompt":70,"zipAvailable":71},[61,64,67],{"tool":62,"command":63},"npx","npx skills add microsoft\u002Fvscode --skill component-fixtures",{"tool":65,"command":66},"bunx","bunx skills add microsoft\u002Fvscode --skill component-fixtures",{"tool":68,"command":69},"pnpm","pnpm dlx skills add microsoft\u002Fvscode --skill component-fixtures","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fcomponent-fixtures\u002FSKILL.md",true,[73,79,83,87,91,95,99,103,107,111],{"path":74,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":77,"sourceHtmlUrl":78},"resources\u002Fcommon-patterns.md","REFERENCE","参考文档",8369,"https:\u002F\u002Fgithub.com\u002Ffel-tte\u002Frobot-forex\u002Fblob\u002Fmain\u002Fclaude-super-kit\u002F.claude\u002Fskills\u002Ffrontend-development\u002Fresources\u002Fcommon-patterns.md",{"path":80,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":81,"sourceHtmlUrl":82},"resources\u002Fcomplete-examples.md",24524,"https:\u002F\u002Fgithub.com\u002Ffel-tte\u002Frobot-forex\u002Fblob\u002Fmain\u002Fclaude-super-kit\u002F.claude\u002Fskills\u002Ffrontend-development\u002Fresources\u002Fcomplete-examples.md",{"path":84,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":85,"sourceHtmlUrl":86},"resources\u002Fcomponent-patterns.md",10804,"https:\u002F\u002Fgithub.com\u002Ffel-tte\u002Frobot-forex\u002Fblob\u002Fmain\u002Fclaude-super-kit\u002F.claude\u002Fskills\u002Ffrontend-development\u002Fresources\u002Fcomponent-patterns.md",{"path":88,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":89,"sourceHtmlUrl":90},"resources\u002Fdata-fetching.md",19817,"https:\u002F\u002Fgithub.com\u002Ffel-tte\u002Frobot-forex\u002Fblob\u002Fmain\u002Fclaude-super-kit\u002F.claude\u002Fskills\u002Ffrontend-development\u002Fresources\u002Fdata-fetching.md",{"path":92,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":93,"sourceHtmlUrl":94},"resources\u002Ffile-organization.md",11871,"https:\u002F\u002Fgithub.com\u002Ffel-tte\u002Frobot-forex\u002Fblob\u002Fmain\u002Fclaude-super-kit\u002F.claude\u002Fskills\u002Ffrontend-development\u002Fresources\u002Ffile-organization.md",{"path":96,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":97,"sourceHtmlUrl":98},"resources\u002Floading-and-error-states.md",12036,"https:\u002F\u002Fgithub.com\u002Ffel-tte\u002Frobot-forex\u002Fblob\u002Fmain\u002Fclaude-super-kit\u002F.claude\u002Fskills\u002Ffrontend-development\u002Fresources\u002Floading-and-error-states.md",{"path":100,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":101,"sourceHtmlUrl":102},"resources\u002Fperformance.md",9639,"https:\u002F\u002Fgithub.com\u002Ffel-tte\u002Frobot-forex\u002Fblob\u002Fmain\u002Fclaude-super-kit\u002F.claude\u002Fskills\u002Ffrontend-development\u002Fresources\u002Fperformance.md",{"path":104,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":105,"sourceHtmlUrl":106},"resources\u002Frouting-guide.md",7193,"https:\u002F\u002Fgithub.com\u002Ffel-tte\u002Frobot-forex\u002Fblob\u002Fmain\u002Fclaude-super-kit\u002F.claude\u002Fskills\u002Ffrontend-development\u002Fresources\u002Frouting-guide.md",{"path":108,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":109,"sourceHtmlUrl":110},"resources\u002Fstyling-guide.md",7905,"https:\u002F\u002Fgithub.com\u002Ffel-tte\u002Frobot-forex\u002Fblob\u002Fmain\u002Fclaude-super-kit\u002F.claude\u002Fskills\u002Ffrontend-development\u002Fresources\u002Fstyling-guide.md",{"path":112,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":113,"sourceHtmlUrl":114},"resources\u002Ftypescript-standards.md",8439,"https:\u002F\u002Fgithub.com\u002Ffel-tte\u002Frobot-forex\u002Fblob\u002Fmain\u002Fclaude-super-kit\u002F.claude\u002Fskills\u002Ffrontend-development\u002Fresources\u002Ftypescript-standards.md",[116,142,164,178,193,209],{"skillNo":117,"name":118,"nameZh":6,"description":119,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":120,"categories":121,"keywords":122,"publishedAt":44},"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",[],[123,124,125,126,127,28,128,129,130,131,132,133,134,135,136,137,138,139,140,141],"sweeper query","query","sweeper","review","fix","request","which","natural-language","ranking","duplicates","ready","only","read","plan","open","Citations","brief","issues","code",{"skillNo":143,"name":144,"nameZh":6,"description":145,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":146,"categories":147,"keywords":148,"publishedAt":44},"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",[],[149,150,29,151,152,153,154,155,156,157,158,159,160,161,162,163,28],"update","update skills","pattern","domain","learnings","reusable","use","session","user","instructions","knowledge","repository","learn","create","sessions",{"skillNo":165,"name":166,"nameZh":6,"description":167,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":168,"categories":169,"keywords":170,"publishedAt":44},"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",[],[149,171,172,28,128,173,29,155,156,157,174,175,176,177],"pr","update pr","Existing","push","pull","pull request","changes",{"skillNo":179,"name":180,"nameZh":6,"description":181,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":182,"categories":183,"keywords":184,"publishedAt":44},"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",[],[180,185,186,174,175,187,28,177,188,189,190,191,155,156,157,192],"SET","publish","rebase","latest","with","remote","upstream","branch",{"skillNo":194,"name":195,"nameZh":6,"description":196,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":197,"categories":198,"keywords":199,"publishedAt":44},"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",[],[191,180,200,201,28,202,203,177,188,204,205,206,207,155,156,192,208,149],"sync upstream","fit","catch","catch up","origin","conflicts","stale","up","work",{"skillNo":210,"name":211,"nameZh":6,"description":212,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":213,"categories":214,"keywords":215,"publishedAt":44},"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",[],[211,156,155,208,192,157,28,216,217,177],"back","base"]