{"owner":"microsoft","repo":"vscode","hasSkills":true,"totalSkillsCount":6,"totalTokensCount":4644,"categories":["root-instruction","copilot-instructions","mcp-config","marketplace","plugin-manifest","cursor-rule"],"hasMcp":true,"mcpConfig":{"mcpServers":{"vscode":{"command":"npx","args":["-y","@modelcontextprotocol/server-vscode"]}}},"found":["AGENTS.md",".github/copilot-instructions.md",".cursor/mcp.json",".claude-plugin/marketplace.json",".claude-plugin/plugin.json",".cursorrules (vscode-extension-dev-typescript-cursorrules-prompt-file.mdc)"],"skills":{"AGENTS.md":"# VS Code Agents Instructions\n\nThis file provides instructions for AI coding agents working with the VS Code codebase.\n\nFor detailed project overview, architecture, coding guidelines, and validation steps, see the [Copilot Instructions](.github/copilot-instructions.md).\n",".github/copilot-instructions.md":"# VS Code Copilot Instructions\n\n## Project Overview\n\nVisual Studio Code is built with a layered architecture using TypeScript, web APIs and Electron, combining web technologies with native app capabilities. The codebase is organized into key architectural layers:\n\n### Root Folders\n- `src/`: Main TypeScript source code with unit tests in `src/vs/*/test/` folders\n- `build/`: Build scripts and CI/CD tools\n- `extensions/`: Built-in extensions that ship with VS Code\n- `test/`: Integration tests and test infrastructure\n- `scripts/`: Development and build scripts\n- `resources/`: Static resources (icons, themes, etc.)\n- `out/`: Compiled JavaScript output (generated during build)\n\n### Core Architecture (`src/` folder)\n- `src/vs/base/` - Foundation utilities and cross-platform abstractions\n- `src/vs/platform/` - Platform services and dependency injection infrastructure\n- `src/vs/editor/` - Text editor implementation with language services, syntax highlighting, and editing features\n- `src/vs/workbench/` - Main application workbench for web and desktop\n  - `workbench/browser/` - Core workbench UI components (parts, layout, actions)\n  - `workbench/services/` - Service implementations\n  - `workbench/contrib/` - Feature contributions (git, debug, search, terminal, etc.)\n  - `workbench/api/` - Extension host and VS Code API implementation\n- `src/vs/code/` - Electron main process specific implementation\n- `src/vs/server/` - Server specific implementation\n- `src/vs/sessions/` - Agent sessions window, a dedicated workbench layer for agentic workflows (sits alongside `vs/workbench`, may import from it but not vice versa)\n\nThe core architecture follows these principles:\n- **Layered architecture** - from `base`, `platform`, `editor`, to `workbench`\n- **Dependency injection** - Services are injected through constructor parameters\n    - If non-service parameters are needed, they need to come before the service parameters\n- **Contribution model** - Features contribute to registries and extension points\n- **Cross-platform compatibility** - Abstractions separate platform-specific code\n\n### Built-in Extensions (`extensions/` folder)\nThe `extensions/` directory contains first-party extensions that ship with VS Code:\n- **Language support** - `typescript-language-features/`, `html-language-features/`, `css-language-features/`, etc.\n- **Core features** - `git/`, `debug-auto-launch/`, `emmet/`, `markdown-language-features/`\n- **Themes** - `theme-*` folders for default color themes\n- **Development tools** - `extension-editing/`, `vscode-api-tests/`\n\nEach extension follows the standard VS Code extension structure with `package.json`, TypeScript sources, and contribution points to extend the workbench through the Extension API.\n\n### Finding Related Code\n1. **Semantic search first**: Use file search for general concepts\n2. **Grep for exact strings**: Use grep for error messages or specific function names\n3. **Follow imports**: Check what files import the problematic module\n4. **Check test files**: Often reveal usage patterns and expected behavior\n\n## Validating TypeScript changes\n\nChoose validation based on the scope and risk of the change. Large-scale builds and typechecking can be slow, and consume significant resources, so minimize their use. Prefer existing editor or watch-task diagnostics and the smallest targeted tests that cover the changed behavior. Do not start build or watch tasks, run broad type checks, or make type checking a prerequisite for targeted tests solely as a completion ritual.\n\nWhen running in a VS Code editor window with a workspace folder, use the VS Code task tools for build and watch workflows: inspect the existing task output first, and run an existing task instead of invoking its equivalent shell command. Do not start a duplicate build or watch process when the workspace task already provides current diagnostics. Agents window chats and isolated worktree sessions may not have access to the editor's workspace tasks; use the repository commands directly in those contexts.\n\nRun a targeted type check or build when you are not fully confident in the change, and the change is broad or cross-cutting, it affects build or type configuration, or another validation step reports a compilation problem. When task tools are unavailable or no suitable task exists, useful commands include:\n\n- `npm run typecheck-client` for the main sources under `src/`\n- `npm run gulp compile-extensions` for built-in extensions\n- `npm run typecheck` from the `build` folder for build tooling\n\nDevelopment compile tasks already type-check their inputs. Do not run `npm run typecheck-client` immediately before `npm run compile` or `npm run compile-client`; choose the command that covers the required validation. When tests only need fresh client output, use `npm run build-fast -- --client-only`. It supports cold builds and file-granular incremental updates without starting a watcher or building extensions. Use `npm run build-fast` when extension and Copilot outputs are also needed. The client and extension JavaScript lanes transpile rather than type-check; extension media retains its existing type checks. Run explicit type checks when the change warrants them. Reserve `npm run transpile-client` for an intentional clean client rebuild.\n\nReuse successful validation while its relevant inputs remain unchanged, including when moving into review, commit, or PR creation. Batch related test selectors in one invocation. Prefer `npm run eslint -- <changed files>` for targeted linting; this wrapper caches results by file content. Install dependencies only when dependency inputs change or validation identifies missing dependencies; use `npm run install-fast` for a needed refresh, which skips up-to-date installations and falls back to `npm install` when required. Never share or symlink `node_modules` between worktrees.\n\nUse `scripts/test.sh` (or `scripts\\test.bat` on Windows) for unit tests and `scripts/test-integration.sh` (or `scripts\\test-integration.bat` on Windows) for integration tests. Add a targeted selector such as `--grep` whenever possible. Run `npm run valid-layers-check` only when a change may affect module layering.\n\n## Coding Guidelines\n\n### Markdown\n\n- Do not hard-wrap Markdown prose to a fixed line width. Keep each paragraph on one source line and let the editor or renderer wrap it naturally. Preserve structural line breaks in lists, tables, code blocks, and intentional Markdown hard breaks.\n\n### Indentation\n\nWe use tabs, not spaces.\n\n### Naming Conventions\n\n- Use PascalCase for `type` names\n- Use PascalCase for `enum` values\n- Use camelCase for `function` and `method` names\n- Use camelCase for `property` names and `local variables`\n- Use whole words in names when possible\n\n### Types\n\n- Do not export `types` or `functions` unless you need to share it across multiple components\n- Do not introduce new `types` or `values` to the global namespace\n\n### Comments\n\n- Use JSDoc style comments for `functions`, `interfaces`, `enums`, and `classes`\n\n### Strings\n\n- Use \"double quotes\" for strings shown to the user that need to be externalized (localized)\n- Use 'single quotes' otherwise\n- All strings visible to the user need to be externalized using the `vs/nls` module\n- Externalized strings must not use string concatenation. Use placeholders instead (`{0}`).\n\n### UI labels\n- Use title-style capitalization for command labels, buttons and menu items (each word is capitalized).\n- Don't capitalize prepositions of four or fewer letters unless it's the first or last word (e.g. \"in\", \"with\", \"for\").\n\n### Designing UI\n- When creating, editing, or reviewing any visual surface, reason in **design terms, not pixels**: name the **feeling** (Calm, Focused, Consistent, Delightful), find the **principle** it breaks, then reach for the **move** (token/tier/ramp) that restores it. Describe a bug by its role/tier/ramp (e.g. \"this overlay is rounded at the control tier\"), not its number.\n- See the [`design-philosophy` skill](skills/design-philosophy/SKILL.md) for the full Values→Principles→Moves vocabulary, worked examples, and feedback guidance, and [design-tokens.instructions.md](instructions/design-tokens.instructions.md) for the token reference.\n\n### Style\n\n- Use arrow functions `=>` over anonymous function expressions\n- Only surround arrow function parameters when necessary. For example, `(x) => x + x` is wrong but the following are correct:\n\n```typescript\nx => x + x\n(x, y) => x + y\n<T>(x: T, y: T) => x === y\n```\n\n- Always surround loop and conditional bodies with curly braces\n- Open curly braces always go on the same line as whatever necessitates them\n- Parenthesized constructs should have no surrounding whitespace. A single space follows commas, colons, and semicolons in those constructs. For example:\n\n```typescript\nfor (let i = 0, n = str.length; i < 10; i++) {\n    if (x < 10) {\n        foo();\n    }\n}\nfunction f(x: number, y: string): void { }\n```\n\n- Whenever possible, in top-level scopes, use `export function x(…) {…}` instead of `export const x = (…) => {…}`. One advantage of using the `function` keyword is that the stack trace shows a good name when debugging.\n\n### Code Quality\n\n- All files must include Microsoft copyright header\n- Prefer `async` and `await` over `Promise` and `then` calls\n- All user facing messages must be localized using the applicable localization framework (for example `nls.localize()` method)\n- Don't add tests to the wrong test suite (e.g., adding to end of file instead of inside relevant suite)\n- Look for existing test patterns before creating new structures\n- Use `describe` and `test` consistently with existing patterns\n- Prefer regex capture groups with names over numbered capture groups.\n- If you create any temporary new files, scripts, or helper files for iteration, clean up these files by removing them at the end of the task\n- Never duplicate imports. Always reuse existing imports if they are present.\n- When removing an import, do not leave behind blank lines where the import was. Ensure the surrounding code remains compact.\n- Do not use `any` or `unknown` as the type for variables, parameters, or return values unless absolutely necessary. If they need type annotations, they should have proper types or interfaces defined.\n- When adding file watching, prefer correlated file watchers (via fileService.createWatcher) to shared ones.\n- When adding tooltips to UI elements, prefer the use of IHoverService service.\n- Do not duplicate code. Always look for existing utility functions, helpers, or patterns in the codebase before implementing new functionality. Reuse and extend existing code whenever possible.\n- You MUST deal with disposables by registering them immediately after creation for later disposal. Use helpers such as `DisposableStore`, `MutableDisposable` or `DisposableMap`. Do NOT register a disposable to the containing class if the object is created within a method that is called repeatedly to avoid leaks. Instead, return an `IDisposable` from such method and let the caller register it.\n- You MUST NOT use storage keys of another component only to make changes to that component. You MUST come up with proper API to change another component.\n- Use `IEditorService` to open editors instead of `IEditorGroupsService.activeGroup.openEditor` to ensure that the editor opening logic is properly followed and to avoid bypassing important features such as `revealIfOpened` or `preserveFocus`.\n- Avoid using `bind()`, `call()` and `apply()` solely to control `this` or partially apply arguments; prefer arrow functions or closures to capture the necessary context, and use these methods only when required by an API or interoperability.\n- Avoid using events to drive control flow between components. Instead, prefer direct method calls or service interactions to ensure clearer dependencies and easier traceability of logic. Events should be reserved for broadcasting state changes or notifications rather than orchestrating behavior across components.\n- Service dependencies MUST be declared in constructors and MUST NOT be accessed through the `IInstantiationService` at any other point in time.\n\n## Learnings\n- Minimize the amount of assertions in tests. Prefer one snapshot-style `assert.deepStrictEqual` over multiple precise assertions, as they are much more difficult to understand and to update.\n- Do not stub a global object (e.g. `(mainWindow as any).ResizeObserver = ...`) or use `any` casts to install fakes in tests. Instead, make the dependency injectable: add an optional constructor parameter on the production class that defaults to the real implementation (e.g. `targetWindow.ResizeObserver`), and have the test pass a fake that implements the real interface.\n",".cursor/mcp.json":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/microsoft/vscode/HEAD/.cursor/mcp.json)",".claude-plugin/marketplace.json":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/microsoft/vscode/HEAD/.claude-plugin/marketplace.json)",".claude-plugin/plugin.json":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/microsoft/vscode/HEAD/.claude-plugin/plugin.json)",".cursorrules (vscode-extension-dev-typescript-cursorrules-prompt-file.mdc)":"---\ndescription: \"Cursor rules for Vscode Extension Dev Typescript.\"\nglobs: **/*\nalwaysApply: false\n---\nYou are an expert in VSCode Extension Development, TypeScript, Node.js, HTML, CSS, VSCode APIs, and Electron.\n\nCode Style and Structure:\n- Write clear, concise TypeScript code following modern ECMAScript standards.\n- Use modular design patterns to separate concerns (e.g., separate commands, UI components, and business logic).\n- Organize your project into meaningful directories such as src, out, and assets.\n- Include comprehensive inline comments and JSDoc annotations for public APIs.\n\nNaming Conventions:\n- Use kebab-case for file and folder names (e.g., my-extension, command-handler.ts).\n- Use camelCase for variables and function names.\n- Use PascalCase for classes and interfaces.\n- Name commands and configuration keys descriptively (e.g., 'extension.activateFeature', 'extension.showOutput').\n\nTypeScript Usage:\n- Leverage TypeScript for static type checking and enhanced developer experience.\n- Use interfaces and types to define extension commands, configuration schemas, and message payloads.\n- Utilize generics, union types, and type guards to create robust and flexible APIs.\n- Configure strict type checking in tsconfig.json to catch potential errors early.\n\nExtension Architecture:\n- Follow the VSCode Extension API guidelines to structure your extension entry point (typically in extension.ts).\n- Register commands, events, and providers within the activate() function.\n- Use dependency injection where possible to manage state and service interactions.\n- Modularize features into separate files or modules to improve maintainability.\n\nManifest (package.json) and Configuration:\n- Define extension metadata, activation events, contributions (commands, menus, keybindings), and configuration in package.json.\n- Follow VSCode’s schema for extension manifests to ensure compatibility and discoverability.\n- Use activation events wisely to minimize performance overhead (e.g., onCommand, onLanguage).\n- Document all configurable options clearly in package.json and corresponding README files.\n\nSecurity and Privacy:\n- Adhere to the principle of least privilege; request only the permissions you need.\n- Validate and sanitize any input or configuration data.\n- Avoid exposing sensitive APIs or secrets within the extension.\n- Implement error handling and logging that do not leak internal state information.\n\nUI and Styling:\n- Use VSCode’s Webview API for custom UIs when necessary; otherwise, leverage the built-in VSCode UI components.\n- Maintain consistency with the VSCode design language to provide a seamless user experience.\n- Use responsive design principles to support different screen sizes and themes (dark/light modes).\n- Structure HTML, CSS, and JavaScript/TypeScript in a way that separates concerns and supports maintainability.\n\nPerformance Optimization:\n- Optimize extension activation by deferring non-critical operations until after activation.\n- Use asynchronous programming (async/await, Promises) to avoid blocking the main thread.\n- Profile and monitor resource usage; consider lazy-loading features to reduce initial load time.\n- Avoid unnecessary file system or network operations during activation.\n\nVSCode API Usage:\n- Familiarize yourself with the official VSCode API and follow its guidelines for registering commands, creating status bar items, handling events, etc.\n- Use vscode.workspace, vscode.window, and vscode.commands to interact with the editor efficiently.\n- Always handle potential errors when calling VSCode APIs to improve extension resilience.\n- Keep up to date with the latest VSCode API changes and deprecations.\n\nCross-platform Compatibility:\n- Ensure your extension works seamlessly across Windows, macOS, and Linux.\n- Test on different environments to identify any OS-specific issues.\n- Use Node.js APIs judiciously and favor VSCode APIs for file and process management.\n\nTesting and Debugging:\n- Write unit tests for core functionality using testing frameworks like Mocha or Jest.\n- Use the VSCode Extension Test Runner for integration tests.\n- Leverage VSCode’s built-in debugging tools to set breakpoints and inspect runtime behavior.\n- Incorporate logging with appropriate levels (info, warn, error) to aid in troubleshooting.\n\nContext-Aware Development:\n- Consider the full project context when integrating new features; ensure consistency with existing functionality.\n- Avoid duplicating code and ensure new components interact seamlessly with current ones.\n- Review user feedback and extension telemetry to continuously refine and optimize your extension.\n- When providing code snippets or solutions, ensure they align with the established project architecture and coding standards.\n\nCode Output:\n- Provide full file contents when sharing code examples to ensure completeness and clarity.\n- Include all necessary imports, module declarations, and surrounding code context.\n- Clearly comment on significant changes or additions to explain the rationale behind decisions.\n- When code snippets are too long, indicate where the snippet fits into the overall project structure.\n\nFollow the official VSCode Extension documentation for best practices, API usage, and security guidelines.\n"},"files":{"AGENTS.md":"# VS Code Agents Instructions\n\nThis file provides instructions for AI coding agents working with the VS Code codebase.\n\nFor detailed project overview, architecture, coding guidelines, and validation steps, see the [Copilot Instructions](.github/copilot-instructions.md).\n",".github/copilot-instructions.md":"# VS Code Copilot Instructions\n\n## Project Overview\n\nVisual Studio Code is built with a layered architecture using TypeScript, web APIs and Electron, combining web technologies with native app capabilities. The codebase is organized into key architectural layers:\n\n### Root Folders\n- `src/`: Main TypeScript source code with unit tests in `src/vs/*/test/` folders\n- `build/`: Build scripts and CI/CD tools\n- `extensions/`: Built-in extensions that ship with VS Code\n- `test/`: Integration tests and test infrastructure\n- `scripts/`: Development and build scripts\n- `resources/`: Static resources (icons, themes, etc.)\n- `out/`: Compiled JavaScript output (generated during build)\n\n### Core Architecture (`src/` folder)\n- `src/vs/base/` - Foundation utilities and cross-platform abstractions\n- `src/vs/platform/` - Platform services and dependency injection infrastructure\n- `src/vs/editor/` - Text editor implementation with language services, syntax highlighting, and editing features\n- `src/vs/workbench/` - Main application workbench for web and desktop\n  - `workbench/browser/` - Core workbench UI components (parts, layout, actions)\n  - `workbench/services/` - Service implementations\n  - `workbench/contrib/` - Feature contributions (git, debug, search, terminal, etc.)\n  - `workbench/api/` - Extension host and VS Code API implementation\n- `src/vs/code/` - Electron main process specific implementation\n- `src/vs/server/` - Server specific implementation\n- `src/vs/sessions/` - Agent sessions window, a dedicated workbench layer for agentic workflows (sits alongside `vs/workbench`, may import from it but not vice versa)\n\nThe core architecture follows these principles:\n- **Layered architecture** - from `base`, `platform`, `editor`, to `workbench`\n- **Dependency injection** - Services are injected through constructor parameters\n    - If non-service parameters are needed, they need to come before the service parameters\n- **Contribution model** - Features contribute to registries and extension points\n- **Cross-platform compatibility** - Abstractions separate platform-specific code\n\n### Built-in Extensions (`extensions/` folder)\nThe `extensions/` directory contains first-party extensions that ship with VS Code:\n- **Language support** - `typescript-language-features/`, `html-language-features/`, `css-language-features/`, etc.\n- **Core features** - `git/`, `debug-auto-launch/`, `emmet/`, `markdown-language-features/`\n- **Themes** - `theme-*` folders for default color themes\n- **Development tools** - `extension-editing/`, `vscode-api-tests/`\n\nEach extension follows the standard VS Code extension structure with `package.json`, TypeScript sources, and contribution points to extend the workbench through the Extension API.\n\n### Finding Related Code\n1. **Semantic search first**: Use file search for general concepts\n2. **Grep for exact strings**: Use grep for error messages or specific function names\n3. **Follow imports**: Check what files import the problematic module\n4. **Check test files**: Often reveal usage patterns and expected behavior\n\n## Validating TypeScript changes\n\nChoose validation based on the scope and risk of the change. Large-scale builds and typechecking can be slow, and consume significant resources, so minimize their use. Prefer existing editor or watch-task diagnostics and the smallest targeted tests that cover the changed behavior. Do not start build or watch tasks, run broad type checks, or make type checking a prerequisite for targeted tests solely as a completion ritual.\n\nWhen running in a VS Code editor window with a workspace folder, use the VS Code task tools for build and watch workflows: inspect the existing task output first, and run an existing task instead of invoking its equivalent shell command. Do not start a duplicate build or watch process when the workspace task already provides current diagnostics. Agents window chats and isolated worktree sessions may not have access to the editor's workspace tasks; use the repository commands directly in those contexts.\n\nRun a targeted type check or build when you are not fully confident in the change, and the change is broad or cross-cutting, it affects build or type configuration, or another validation step reports a compilation problem. When task tools are unavailable or no suitable task exists, useful commands include:\n\n- `npm run typecheck-client` for the main sources under `src/`\n- `npm run gulp compile-extensions` for built-in extensions\n- `npm run typecheck` from the `build` folder for build tooling\n\nDevelopment compile tasks already type-check their inputs. Do not run `npm run typecheck-client` immediately before `npm run compile` or `npm run compile-client`; choose the command that covers the required validation. When tests only need fresh client output, use `npm run build-fast -- --client-only`. It supports cold builds and file-granular incremental updates without starting a watcher or building extensions. Use `npm run build-fast` when extension and Copilot outputs are also needed. The client and extension JavaScript lanes transpile rather than type-check; extension media retains its existing type checks. Run explicit type checks when the change warrants them. Reserve `npm run transpile-client` for an intentional clean client rebuild.\n\nReuse successful validation while its relevant inputs remain unchanged, including when moving into review, commit, or PR creation. Batch related test selectors in one invocation. Prefer `npm run eslint -- <changed files>` for targeted linting; this wrapper caches results by file content. Install dependencies only when dependency inputs change or validation identifies missing dependencies; use `npm run install-fast` for a needed refresh, which skips up-to-date installations and falls back to `npm install` when required. Never share or symlink `node_modules` between worktrees.\n\nUse `scripts/test.sh` (or `scripts\\test.bat` on Windows) for unit tests and `scripts/test-integration.sh` (or `scripts\\test-integration.bat` on Windows) for integration tests. Add a targeted selector such as `--grep` whenever possible. Run `npm run valid-layers-check` only when a change may affect module layering.\n\n## Coding Guidelines\n\n### Markdown\n\n- Do not hard-wrap Markdown prose to a fixed line width. Keep each paragraph on one source line and let the editor or renderer wrap it naturally. Preserve structural line breaks in lists, tables, code blocks, and intentional Markdown hard breaks.\n\n### Indentation\n\nWe use tabs, not spaces.\n\n### Naming Conventions\n\n- Use PascalCase for `type` names\n- Use PascalCase for `enum` values\n- Use camelCase for `function` and `method` names\n- Use camelCase for `property` names and `local variables`\n- Use whole words in names when possible\n\n### Types\n\n- Do not export `types` or `functions` unless you need to share it across multiple components\n- Do not introduce new `types` or `values` to the global namespace\n\n### Comments\n\n- Use JSDoc style comments for `functions`, `interfaces`, `enums`, and `classes`\n\n### Strings\n\n- Use \"double quotes\" for strings shown to the user that need to be externalized (localized)\n- Use 'single quotes' otherwise\n- All strings visible to the user need to be externalized using the `vs/nls` module\n- Externalized strings must not use string concatenation. Use placeholders instead (`{0}`).\n\n### UI labels\n- Use title-style capitalization for command labels, buttons and menu items (each word is capitalized).\n- Don't capitalize prepositions of four or fewer letters unless it's the first or last word (e.g. \"in\", \"with\", \"for\").\n\n### Designing UI\n- When creating, editing, or reviewing any visual surface, reason in **design terms, not pixels**: name the **feeling** (Calm, Focused, Consistent, Delightful), find the **principle** it breaks, then reach for the **move** (token/tier/ramp) that restores it. Describe a bug by its role/tier/ramp (e.g. \"this overlay is rounded at the control tier\"), not its number.\n- See the [`design-philosophy` skill](skills/design-philosophy/SKILL.md) for the full Values→Principles→Moves vocabulary, worked examples, and feedback guidance, and [design-tokens.instructions.md](instructions/design-tokens.instructions.md) for the token reference.\n\n### Style\n\n- Use arrow functions `=>` over anonymous function expressions\n- Only surround arrow function parameters when necessary. For example, `(x) => x + x` is wrong but the following are correct:\n\n```typescript\nx => x + x\n(x, y) => x + y\n<T>(x: T, y: T) => x === y\n```\n\n- Always surround loop and conditional bodies with curly braces\n- Open curly braces always go on the same line as whatever necessitates them\n- Parenthesized constructs should have no surrounding whitespace. A single space follows commas, colons, and semicolons in those constructs. For example:\n\n```typescript\nfor (let i = 0, n = str.length; i < 10; i++) {\n    if (x < 10) {\n        foo();\n    }\n}\nfunction f(x: number, y: string): void { }\n```\n\n- Whenever possible, in top-level scopes, use `export function x(…) {…}` instead of `export const x = (…) => {…}`. One advantage of using the `function` keyword is that the stack trace shows a good name when debugging.\n\n### Code Quality\n\n- All files must include Microsoft copyright header\n- Prefer `async` and `await` over `Promise` and `then` calls\n- All user facing messages must be localized using the applicable localization framework (for example `nls.localize()` method)\n- Don't add tests to the wrong test suite (e.g., adding to end of file instead of inside relevant suite)\n- Look for existing test patterns before creating new structures\n- Use `describe` and `test` consistently with existing patterns\n- Prefer regex capture groups with names over numbered capture groups.\n- If you create any temporary new files, scripts, or helper files for iteration, clean up these files by removing them at the end of the task\n- Never duplicate imports. Always reuse existing imports if they are present.\n- When removing an import, do not leave behind blank lines where the import was. Ensure the surrounding code remains compact.\n- Do not use `any` or `unknown` as the type for variables, parameters, or return values unless absolutely necessary. If they need type annotations, they should have proper types or interfaces defined.\n- When adding file watching, prefer correlated file watchers (via fileService.createWatcher) to shared ones.\n- When adding tooltips to UI elements, prefer the use of IHoverService service.\n- Do not duplicate code. Always look for existing utility functions, helpers, or patterns in the codebase before implementing new functionality. Reuse and extend existing code whenever possible.\n- You MUST deal with disposables by registering them immediately after creation for later disposal. Use helpers such as `DisposableStore`, `MutableDisposable` or `DisposableMap`. Do NOT register a disposable to the containing class if the object is created within a method that is called repeatedly to avoid leaks. Instead, return an `IDisposable` from such method and let the caller register it.\n- You MUST NOT use storage keys of another component only to make changes to that component. You MUST come up with proper API to change another component.\n- Use `IEditorService` to open editors instead of `IEditorGroupsService.activeGroup.openEditor` to ensure that the editor opening logic is properly followed and to avoid bypassing important features such as `revealIfOpened` or `preserveFocus`.\n- Avoid using `bind()`, `call()` and `apply()` solely to control `this` or partially apply arguments; prefer arrow functions or closures to capture the necessary context, and use these methods only when required by an API or interoperability.\n- Avoid using events to drive control flow between components. Instead, prefer direct method calls or service interactions to ensure clearer dependencies and easier traceability of logic. Events should be reserved for broadcasting state changes or notifications rather than orchestrating behavior across components.\n- Service dependencies MUST be declared in constructors and MUST NOT be accessed through the `IInstantiationService` at any other point in time.\n\n## Learnings\n- Minimize the amount of assertions in tests. Prefer one snapshot-style `assert.deepStrictEqual` over multiple precise assertions, as they are much more difficult to understand and to update.\n- Do not stub a global object (e.g. `(mainWindow as any).ResizeObserver = ...`) or use `any` casts to install fakes in tests. Instead, make the dependency injectable: add an optional constructor parameter on the production class that defaults to the real implementation (e.g. `targetWindow.ResizeObserver`), and have the test pass a fake that implements the real interface.\n",".cursor/mcp.json":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/microsoft/vscode/HEAD/.cursor/mcp.json)",".claude-plugin/marketplace.json":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/microsoft/vscode/HEAD/.claude-plugin/marketplace.json)",".claude-plugin/plugin.json":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/microsoft/vscode/HEAD/.claude-plugin/plugin.json)",".cursorrules (vscode-extension-dev-typescript-cursorrules-prompt-file.mdc)":"---\ndescription: \"Cursor rules for Vscode Extension Dev Typescript.\"\nglobs: **/*\nalwaysApply: false\n---\nYou are an expert in VSCode Extension Development, TypeScript, Node.js, HTML, CSS, VSCode APIs, and Electron.\n\nCode Style and Structure:\n- Write clear, concise TypeScript code following modern ECMAScript standards.\n- Use modular design patterns to separate concerns (e.g., separate commands, UI components, and business logic).\n- Organize your project into meaningful directories such as src, out, and assets.\n- Include comprehensive inline comments and JSDoc annotations for public APIs.\n\nNaming Conventions:\n- Use kebab-case for file and folder names (e.g., my-extension, command-handler.ts).\n- Use camelCase for variables and function names.\n- Use PascalCase for classes and interfaces.\n- Name commands and configuration keys descriptively (e.g., 'extension.activateFeature', 'extension.showOutput').\n\nTypeScript Usage:\n- Leverage TypeScript for static type checking and enhanced developer experience.\n- Use interfaces and types to define extension commands, configuration schemas, and message payloads.\n- Utilize generics, union types, and type guards to create robust and flexible APIs.\n- Configure strict type checking in tsconfig.json to catch potential errors early.\n\nExtension Architecture:\n- Follow the VSCode Extension API guidelines to structure your extension entry point (typically in extension.ts).\n- Register commands, events, and providers within the activate() function.\n- Use dependency injection where possible to manage state and service interactions.\n- Modularize features into separate files or modules to improve maintainability.\n\nManifest (package.json) and Configuration:\n- Define extension metadata, activation events, contributions (commands, menus, keybindings), and configuration in package.json.\n- Follow VSCode’s schema for extension manifests to ensure compatibility and discoverability.\n- Use activation events wisely to minimize performance overhead (e.g., onCommand, onLanguage).\n- Document all configurable options clearly in package.json and corresponding README files.\n\nSecurity and Privacy:\n- Adhere to the principle of least privilege; request only the permissions you need.\n- Validate and sanitize any input or configuration data.\n- Avoid exposing sensitive APIs or secrets within the extension.\n- Implement error handling and logging that do not leak internal state information.\n\nUI and Styling:\n- Use VSCode’s Webview API for custom UIs when necessary; otherwise, leverage the built-in VSCode UI components.\n- Maintain consistency with the VSCode design language to provide a seamless user experience.\n- Use responsive design principles to support different screen sizes and themes (dark/light modes).\n- Structure HTML, CSS, and JavaScript/TypeScript in a way that separates concerns and supports maintainability.\n\nPerformance Optimization:\n- Optimize extension activation by deferring non-critical operations until after activation.\n- Use asynchronous programming (async/await, Promises) to avoid blocking the main thread.\n- Profile and monitor resource usage; consider lazy-loading features to reduce initial load time.\n- Avoid unnecessary file system or network operations during activation.\n\nVSCode API Usage:\n- Familiarize yourself with the official VSCode API and follow its guidelines for registering commands, creating status bar items, handling events, etc.\n- Use vscode.workspace, vscode.window, and vscode.commands to interact with the editor efficiently.\n- Always handle potential errors when calling VSCode APIs to improve extension resilience.\n- Keep up to date with the latest VSCode API changes and deprecations.\n\nCross-platform Compatibility:\n- Ensure your extension works seamlessly across Windows, macOS, and Linux.\n- Test on different environments to identify any OS-specific issues.\n- Use Node.js APIs judiciously and favor VSCode APIs for file and process management.\n\nTesting and Debugging:\n- Write unit tests for core functionality using testing frameworks like Mocha or Jest.\n- Use the VSCode Extension Test Runner for integration tests.\n- Leverage VSCode’s built-in debugging tools to set breakpoints and inspect runtime behavior.\n- Incorporate logging with appropriate levels (info, warn, error) to aid in troubleshooting.\n\nContext-Aware Development:\n- Consider the full project context when integrating new features; ensure consistency with existing functionality.\n- Avoid duplicating code and ensure new components interact seamlessly with current ones.\n- Review user feedback and extension telemetry to continuously refine and optimize your extension.\n- When providing code snippets or solutions, ensure they align with the established project architecture and coding standards.\n\nCode Output:\n- Provide full file contents when sharing code examples to ensure completeness and clarity.\n- Include all necessary imports, module declarations, and surrounding code context.\n- Clearly comment on significant changes or additions to explain the rationale behind decisions.\n- When code snippets are too long, indicate where the snippet fits into the overall project structure.\n\nFollow the official VSCode Extension documentation for best practices, API usage, and security guidelines.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/microsoft/vscode/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# VS Code Agents Instructions\n\nThis file provides instructions for AI coding agents working with the VS Code codebase.\n\nFor detailed project overview, architecture, coding guidelines, and validation steps, see the [Copilot Instructions](.github/copilot-instructions.md).\n","isInternal":false,"tokens":51,"sizeBytes":271},{"name":"copilot-instructions.md","path":".github/copilot-instructions.md","rawUrl":"https://raw.githubusercontent.com/microsoft/vscode/HEAD/.github/copilot-instructions.md","title":"GitHub Copilot Instructions","category":"copilot-instructions","format":"markdown","content":"# VS Code Copilot Instructions\n\n## Project Overview\n\nVisual Studio Code is built with a layered architecture using TypeScript, web APIs and Electron, combining web technologies with native app capabilities. The codebase is organized into key architectural layers:\n\n### Root Folders\n- `src/`: Main TypeScript source code with unit tests in `src/vs/*/test/` folders\n- `build/`: Build scripts and CI/CD tools\n- `extensions/`: Built-in extensions that ship with VS Code\n- `test/`: Integration tests and test infrastructure\n- `scripts/`: Development and build scripts\n- `resources/`: Static resources (icons, themes, etc.)\n- `out/`: Compiled JavaScript output (generated during build)\n\n### Core Architecture (`src/` folder)\n- `src/vs/base/` - Foundation utilities and cross-platform abstractions\n- `src/vs/platform/` - Platform services and dependency injection infrastructure\n- `src/vs/editor/` - Text editor implementation with language services, syntax highlighting, and editing features\n- `src/vs/workbench/` - Main application workbench for web and desktop\n  - `workbench/browser/` - Core workbench UI components (parts, layout, actions)\n  - `workbench/services/` - Service implementations\n  - `workbench/contrib/` - Feature contributions (git, debug, search, terminal, etc.)\n  - `workbench/api/` - Extension host and VS Code API implementation\n- `src/vs/code/` - Electron main process specific implementation\n- `src/vs/server/` - Server specific implementation\n- `src/vs/sessions/` - Agent sessions window, a dedicated workbench layer for agentic workflows (sits alongside `vs/workbench`, may import from it but not vice versa)\n\nThe core architecture follows these principles:\n- **Layered architecture** - from `base`, `platform`, `editor`, to `workbench`\n- **Dependency injection** - Services are injected through constructor parameters\n    - If non-service parameters are needed, they need to come before the service parameters\n- **Contribution model** - Features contribute to registries and extension points\n- **Cross-platform compatibility** - Abstractions separate platform-specific code\n\n### Built-in Extensions (`extensions/` folder)\nThe `extensions/` directory contains first-party extensions that ship with VS Code:\n- **Language support** - `typescript-language-features/`, `html-language-features/`, `css-language-features/`, etc.\n- **Core features** - `git/`, `debug-auto-launch/`, `emmet/`, `markdown-language-features/`\n- **Themes** - `theme-*` folders for default color themes\n- **Development tools** - `extension-editing/`, `vscode-api-tests/`\n\nEach extension follows the standard VS Code extension structure with `package.json`, TypeScript sources, and contribution points to extend the workbench through the Extension API.\n\n### Finding Related Code\n1. **Semantic search first**: Use file search for general concepts\n2. **Grep for exact strings**: Use grep for error messages or specific function names\n3. **Follow imports**: Check what files import the problematic module\n4. **Check test files**: Often reveal usage patterns and expected behavior\n\n## Validating TypeScript changes\n\nChoose validation based on the scope and risk of the change. Large-scale builds and typechecking can be slow, and consume significant resources, so minimize their use. Prefer existing editor or watch-task diagnostics and the smallest targeted tests that cover the changed behavior. Do not start build or watch tasks, run broad type checks, or make type checking a prerequisite for targeted tests solely as a completion ritual.\n\nWhen running in a VS Code editor window with a workspace folder, use the VS Code task tools for build and watch workflows: inspect the existing task output first, and run an existing task instead of invoking its equivalent shell command. Do not start a duplicate build or watch process when the workspace task already provides current diagnostics. Agents window chats and isolated worktree sessions may not have access to the editor's workspace tasks; use the repository commands directly in those contexts.\n\nRun a targeted type check or build when you are not fully confident in the change, and the change is broad or cross-cutting, it affects build or type configuration, or another validation step reports a compilation problem. When task tools are unavailable or no suitable task exists, useful commands include:\n\n- `npm run typecheck-client` for the main sources under `src/`\n- `npm run gulp compile-extensions` for built-in extensions\n- `npm run typecheck` from the `build` folder for build tooling\n\nDevelopment compile tasks already type-check their inputs. Do not run `npm run typecheck-client` immediately before `npm run compile` or `npm run compile-client`; choose the command that covers the required validation. When tests only need fresh client output, use `npm run build-fast -- --client-only`. It supports cold builds and file-granular incremental updates without starting a watcher or building extensions. Use `npm run build-fast` when extension and Copilot outputs are also needed. The client and extension JavaScript lanes transpile rather than type-check; extension media retains its existing type checks. Run explicit type checks when the change warrants them. Reserve `npm run transpile-client` for an intentional clean client rebuild.\n\nReuse successful validation while its relevant inputs remain unchanged, including when moving into review, commit, or PR creation. Batch related test selectors in one invocation. Prefer `npm run eslint -- <changed files>` for targeted linting; this wrapper caches results by file content. Install dependencies only when dependency inputs change or validation identifies missing dependencies; use `npm run install-fast` for a needed refresh, which skips up-to-date installations and falls back to `npm install` when required. Never share or symlink `node_modules` between worktrees.\n\nUse `scripts/test.sh` (or `scripts\\test.bat` on Windows) for unit tests and `scripts/test-integration.sh` (or `scripts\\test-integration.bat` on Windows) for integration tests. Add a targeted selector such as `--grep` whenever possible. Run `npm run valid-layers-check` only when a change may affect module layering.\n\n## Coding Guidelines\n\n### Markdown\n\n- Do not hard-wrap Markdown prose to a fixed line width. Keep each paragraph on one source line and let the editor or renderer wrap it naturally. Preserve structural line breaks in lists, tables, code blocks, and intentional Markdown hard breaks.\n\n### Indentation\n\nWe use tabs, not spaces.\n\n### Naming Conventions\n\n- Use PascalCase for `type` names\n- Use PascalCase for `enum` values\n- Use camelCase for `function` and `method` names\n- Use camelCase for `property` names and `local variables`\n- Use whole words in names when possible\n\n### Types\n\n- Do not export `types` or `functions` unless you need to share it across multiple components\n- Do not introduce new `types` or `values` to the global namespace\n\n### Comments\n\n- Use JSDoc style comments for `functions`, `interfaces`, `enums`, and `classes`\n\n### Strings\n\n- Use \"double quotes\" for strings shown to the user that need to be externalized (localized)\n- Use 'single quotes' otherwise\n- All strings visible to the user need to be externalized using the `vs/nls` module\n- Externalized strings must not use string concatenation. Use placeholders instead (`{0}`).\n\n### UI labels\n- Use title-style capitalization for command labels, buttons and menu items (each word is capitalized).\n- Don't capitalize prepositions of four or fewer letters unless it's the first or last word (e.g. \"in\", \"with\", \"for\").\n\n### Designing UI\n- When creating, editing, or reviewing any visual surface, reason in **design terms, not pixels**: name the **feeling** (Calm, Focused, Consistent, Delightful), find the **principle** it breaks, then reach for the **move** (token/tier/ramp) that restores it. Describe a bug by its role/tier/ramp (e.g. \"this overlay is rounded at the control tier\"), not its number.\n- See the [`design-philosophy` skill](skills/design-philosophy/SKILL.md) for the full Values→Principles→Moves vocabulary, worked examples, and feedback guidance, and [design-tokens.instructions.md](instructions/design-tokens.instructions.md) for the token reference.\n\n### Style\n\n- Use arrow functions `=>` over anonymous function expressions\n- Only surround arrow function parameters when necessary. For example, `(x) => x + x` is wrong but the following are correct:\n\n```typescript\nx => x + x\n(x, y) => x + y\n<T>(x: T, y: T) => x === y\n```\n\n- Always surround loop and conditional bodies with curly braces\n- Open curly braces always go on the same line as whatever necessitates them\n- Parenthesized constructs should have no surrounding whitespace. A single space follows commas, colons, and semicolons in those constructs. For example:\n\n```typescript\nfor (let i = 0, n = str.length; i < 10; i++) {\n    if (x < 10) {\n        foo();\n    }\n}\nfunction f(x: number, y: string): void { }\n```\n\n- Whenever possible, in top-level scopes, use `export function x(…) {…}` instead of `export const x = (…) => {…}`. One advantage of using the `function` keyword is that the stack trace shows a good name when debugging.\n\n### Code Quality\n\n- All files must include Microsoft copyright header\n- Prefer `async` and `await` over `Promise` and `then` calls\n- All user facing messages must be localized using the applicable localization framework (for example `nls.localize()` method)\n- Don't add tests to the wrong test suite (e.g., adding to end of file instead of inside relevant suite)\n- Look for existing test patterns before creating new structures\n- Use `describe` and `test` consistently with existing patterns\n- Prefer regex capture groups with names over numbered capture groups.\n- If you create any temporary new files, scripts, or helper files for iteration, clean up these files by removing them at the end of the task\n- Never duplicate imports. Always reuse existing imports if they are present.\n- When removing an import, do not leave behind blank lines where the import was. Ensure the surrounding code remains compact.\n- Do not use `any` or `unknown` as the type for variables, parameters, or return values unless absolutely necessary. If they need type annotations, they should have proper types or interfaces defined.\n- When adding file watching, prefer correlated file watchers (via fileService.createWatcher) to shared ones.\n- When adding tooltips to UI elements, prefer the use of IHoverService service.\n- Do not duplicate code. Always look for existing utility functions, helpers, or patterns in the codebase before implementing new functionality. Reuse and extend existing code whenever possible.\n- You MUST deal with disposables by registering them immediately after creation for later disposal. Use helpers such as `DisposableStore`, `MutableDisposable` or `DisposableMap`. Do NOT register a disposable to the containing class if the object is created within a method that is called repeatedly to avoid leaks. Instead, return an `IDisposable` from such method and let the caller register it.\n- You MUST NOT use storage keys of another component only to make changes to that component. You MUST come up with proper API to change another component.\n- Use `IEditorService` to open editors instead of `IEditorGroupsService.activeGroup.openEditor` to ensure that the editor opening logic is properly followed and to avoid bypassing important features such as `revealIfOpened` or `preserveFocus`.\n- Avoid using `bind()`, `call()` and `apply()` solely to control `this` or partially apply arguments; prefer arrow functions or closures to capture the necessary context, and use these methods only when required by an API or interoperability.\n- Avoid using events to drive control flow between components. Instead, prefer direct method calls or service interactions to ensure clearer dependencies and easier traceability of logic. Events should be reserved for broadcasting state changes or notifications rather than orchestrating behavior across components.\n- Service dependencies MUST be declared in constructors and MUST NOT be accessed through the `IInstantiationService` at any other point in time.\n\n## Learnings\n- Minimize the amount of assertions in tests. Prefer one snapshot-style `assert.deepStrictEqual` over multiple precise assertions, as they are much more difficult to understand and to update.\n- Do not stub a global object (e.g. `(mainWindow as any).ResizeObserver = ...`) or use `any` casts to install fakes in tests. Instead, make the dependency injectable: add an optional constructor parameter on the production class that defaults to the real implementation (e.g. `targetWindow.ResizeObserver`), and have the test pass a fake that implements the real interface.\n","isInternal":false,"tokens":2724,"sizeBytes":12759},{"name":"marketplace.json","path":".claude-plugin/marketplace.json","rawUrl":"https://raw.githubusercontent.com/microsoft/vscode/HEAD/.claude-plugin/marketplace.json","title":"Claude Plugin Marketplace Catalog","category":"marketplace","format":"json","content":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/microsoft/vscode/HEAD/.claude-plugin/marketplace.json)","tokens":300,"sizeBytes":195},{"name":"plugin.json","path":".claude-plugin/plugin.json","rawUrl":"https://raw.githubusercontent.com/microsoft/vscode/HEAD/.claude-plugin/plugin.json","title":"claude-plugin Plugin Manifest","category":"plugin-manifest","format":"json","content":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/microsoft/vscode/HEAD/.claude-plugin/plugin.json)","tokens":300,"sizeBytes":181},{"name":"mcp.json","path":".cursor/mcp.json","rawUrl":"https://raw.githubusercontent.com/microsoft/vscode/HEAD/.cursor/mcp.json","title":"Model Context Protocol (MCP) Configuration","category":"mcp-config","format":"json","content":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/microsoft/vscode/HEAD/.cursor/mcp.json)","tokens":300,"sizeBytes":174},{"name":".cursorrules","path":".cursorrules (vscode-extension-dev-typescript-cursorrules-prompt-file.mdc)","rawUrl":"https://raw.githubusercontent.com/PatrickJS/awesome-cursorrules/main/rules/vscode-extension-dev-typescript-cursorrules-prompt-file.mdc","title":"Awesome Cursorrules: vscode extension dev typescript","category":"cursor-rule","format":"markdown","content":"---\ndescription: \"Cursor rules for Vscode Extension Dev Typescript.\"\nglobs: **/*\nalwaysApply: false\n---\nYou are an expert in VSCode Extension Development, TypeScript, Node.js, HTML, CSS, VSCode APIs, and Electron.\n\nCode Style and Structure:\n- Write clear, concise TypeScript code following modern ECMAScript standards.\n- Use modular design patterns to separate concerns (e.g., separate commands, UI components, and business logic).\n- Organize your project into meaningful directories such as src, out, and assets.\n- Include comprehensive inline comments and JSDoc annotations for public APIs.\n\nNaming Conventions:\n- Use kebab-case for file and folder names (e.g., my-extension, command-handler.ts).\n- Use camelCase for variables and function names.\n- Use PascalCase for classes and interfaces.\n- Name commands and configuration keys descriptively (e.g., 'extension.activateFeature', 'extension.showOutput').\n\nTypeScript Usage:\n- Leverage TypeScript for static type checking and enhanced developer experience.\n- Use interfaces and types to define extension commands, configuration schemas, and message payloads.\n- Utilize generics, union types, and type guards to create robust and flexible APIs.\n- Configure strict type checking in tsconfig.json to catch potential errors early.\n\nExtension Architecture:\n- Follow the VSCode Extension API guidelines to structure your extension entry point (typically in extension.ts).\n- Register commands, events, and providers within the activate() function.\n- Use dependency injection where possible to manage state and service interactions.\n- Modularize features into separate files or modules to improve maintainability.\n\nManifest (package.json) and Configuration:\n- Define extension metadata, activation events, contributions (commands, menus, keybindings), and configuration in package.json.\n- Follow VSCode’s schema for extension manifests to ensure compatibility and discoverability.\n- Use activation events wisely to minimize performance overhead (e.g., onCommand, onLanguage).\n- Document all configurable options clearly in package.json and corresponding README files.\n\nSecurity and Privacy:\n- Adhere to the principle of least privilege; request only the permissions you need.\n- Validate and sanitize any input or configuration data.\n- Avoid exposing sensitive APIs or secrets within the extension.\n- Implement error handling and logging that do not leak internal state information.\n\nUI and Styling:\n- Use VSCode’s Webview API for custom UIs when necessary; otherwise, leverage the built-in VSCode UI components.\n- Maintain consistency with the VSCode design language to provide a seamless user experience.\n- Use responsive design principles to support different screen sizes and themes (dark/light modes).\n- Structure HTML, CSS, and JavaScript/TypeScript in a way that separates concerns and supports maintainability.\n\nPerformance Optimization:\n- Optimize extension activation by deferring non-critical operations until after activation.\n- Use asynchronous programming (async/await, Promises) to avoid blocking the main thread.\n- Profile and monitor resource usage; consider lazy-loading features to reduce initial load time.\n- Avoid unnecessary file system or network operations during activation.\n\nVSCode API Usage:\n- Familiarize yourself with the official VSCode API and follow its guidelines for registering commands, creating status bar items, handling events, etc.\n- Use vscode.workspace, vscode.window, and vscode.commands to interact with the editor efficiently.\n- Always handle potential errors when calling VSCode APIs to improve extension resilience.\n- Keep up to date with the latest VSCode API changes and deprecations.\n\nCross-platform Compatibility:\n- Ensure your extension works seamlessly across Windows, macOS, and Linux.\n- Test on different environments to identify any OS-specific issues.\n- Use Node.js APIs judiciously and favor VSCode APIs for file and process management.\n\nTesting and Debugging:\n- Write unit tests for core functionality using testing frameworks like Mocha or Jest.\n- Use the VSCode Extension Test Runner for integration tests.\n- Leverage VSCode’s built-in debugging tools to set breakpoints and inspect runtime behavior.\n- Incorporate logging with appropriate levels (info, warn, error) to aid in troubleshooting.\n\nContext-Aware Development:\n- Consider the full project context when integrating new features; ensure consistency with existing functionality.\n- Avoid duplicating code and ensure new components interact seamlessly with current ones.\n- Review user feedback and extension telemetry to continuously refine and optimize your extension.\n- When providing code snippets or solutions, ensure they align with the established project architecture and coding standards.\n\nCode Output:\n- Provide full file contents when sharing code examples to ensure completeness and clarity.\n- Include all necessary imports, module declarations, and surrounding code context.\n- Clearly comment on significant changes or additions to explain the rationale behind decisions.\n- When code snippets are too long, indicate where the snippet fits into the overall project structure.\n\nFollow the official VSCode Extension documentation for best practices, API usage, and security guidelines.\n","tokens":969,"sizeBytes":5261}],"systemPromptSnippet":"<yakaai_skills repo=\"microsoft/vscode\">\n<!-- File: AGENTS.md (Tokens: ~51 | Category: root-instruction) -->\n# VS Code Agents Instructions\n\nThis file provides instructions for AI coding agents working with the VS Code codebase.\n\nFor detailed project overview, architecture, coding guidelines, and validation steps, see the [Copilot Instructions](.github/copilot-instructions.md).\n\n<!-- File: .github/copilot-instructions.md (Tokens: ~2724 | Category: copilot-instructions) -->\n# VS Code Copilot Instructions\n\n## Project Overview\n\nVisual Studio Code is built with a layered architecture using TypeScript, web APIs and Electron, combining web technologies with native app capabilities. The codebase is organized into key architectural layers:\n\n### Root Folders\n- `src/`: Main TypeScript source code with unit tests in `src/vs/*/test/` folders\n- `build/`: Build scripts and CI/CD tools\n- `extensions/`: Built-in extensions that ship with VS Code\n- `test/`: Integration tests and test infrastructure\n- `scripts/`: Development and build scripts\n- `resources/`: Static resources (icons, themes, etc.)\n- `out/`: Compiled JavaScript output (generated during build)\n\n### Core Architecture (`src/` folder)\n- `src/vs/base/` - Foundation utilities and cross-platform abstractions\n- `src/vs/platform/` - Platform services and dependency injection infrastructure\n- `src/vs/editor/` - Text editor implementation with language services, syntax highlighting, and editing features\n- `src/vs/workbench/` - Main application workbench for web and desktop\n  - `workbench/browser/` - Core workbench UI components (parts, layout, actions)\n  - `workbench/services/` - Service implementations\n  - `workbench/contrib/` - Feature contributions (git, debug, search, terminal, etc.)\n  - `workbench/api/` - Extension host and VS Code API implementation\n- `src/vs/code/` - Electron main process specific implementation\n- `src/vs/server/` - Server specific implementation\n- `src/vs/sessions/` - Agent sessions window, a dedicated workbench layer for agentic workflows (sits alongside `vs/workbench`, may import from it but not vice versa)\n\nThe core architecture follows these principles:\n- **Layered architecture** - from `base`, `platform`, `editor`, to `workbench`\n- **Dependency injection** - Services are injected through constructor parameters\n    - If non-service parameters are needed, they need to come before the service parameters\n- **Contribution model** - Features contribute to registries and extension points\n- **Cross-platform compatibility** - Abstractions separate platform-specific code\n\n### Built-in Extensions (`extensions/` folder)\nThe `extensions/` directory contains first-party extensions that ship with VS Code:\n- **Language support** - `typescript-language-features/`, `html-language-features/`, `css-language-features/`, etc.\n- **Core features** - `git/`, `debug-auto-launch/`, `emmet/`, `markdown-language-features/`\n- **Themes** - `theme-*` folders for default color themes\n- **Development tools** - `extension-editing/`, `vscode-api-tests/`\n\nEach extension follows the standard VS Code extension structure with `package.json`, TypeScript sources, and contribution points to extend the workbench through the Extension API.\n\n### Finding Related Code\n1. **Semantic search first**: Use file search for general concepts\n2. **Grep for exact strings**: Use grep for error messages or specific function names\n3. **Follow imports**: Check what files import the problematic module\n4. **Check test files**: Often reveal usage patterns and expected behavior\n\n## Validating TypeScript changes\n\nChoose validation based on the scope and risk of the change. Large-scale builds and typechecking can be slow, and consume significant resources, so minimize their use. Prefer existing editor or watch-task diagnostics and the smallest targeted tests that cover the changed behavior. Do not start build or watch tasks, run broad type checks, or make type checking a prerequisite for targeted tests solely as a completion ritual.\n\nWhen running in a VS Code editor window with a workspace folder, use the VS Code task tools for build and watch workflows: inspect the existing task output first, and run an existing task instead of invoking its equivalent shell command. Do not start a duplicate build or watch process when the workspace task already provides current diagnostics. Agents window chats and isolated worktree sessions may not have access to the editor's workspace tasks; use the repository commands directly in those contexts.\n\nRun a targeted type check or build when you are not fully confident in the change, and the change is broad or cross-cutting, it affects build or type configuration, or another validation step reports a compilation problem. When task tools are unavailable or no suitable task exists, useful commands include:\n\n- `npm run typecheck-client` for the main sources under `src/`\n- `npm run gulp compile-extensions` for built-in extensions\n- `npm run typecheck` from the `build` folder for build tooling\n\nDevelopment compile tasks already type-check their inputs. Do not run `npm run typecheck-client` immediately before `npm run compile` or `npm run compile-client`; choose the command that covers the required validation. When tests only need fresh client output, use `npm run build-fast -- --client-only`. It supports cold builds and file-granular incremental updates without starting a watcher or building extensions. Use `npm run build-fast` when extension and Copilot outputs are also needed. The client and extension JavaScript lanes transpile rather than type-check; extension media retains its existing type checks. Run explicit type checks when the change warrants them. Reserve `npm run transpile-client` for an intentional clean client rebuild.\n\nReuse successful validation while its relevant inputs remain unchanged, including when moving into review, commit, or PR creation. Batch related test selectors in one invocation. Prefer `npm run eslint -- <changed files>` for targeted linting; this wrapper caches results by file content. Install dependencies only when dependency inputs change or validation identifies missing dependencies; use `npm run install-fast` for a needed refresh, which skips up-to-date installations and falls back to `npm install` when required. Never share or symlink `node_modules` between worktrees.\n\nUse `scripts/test.sh` (or `scripts\\test.bat` on Windows) for unit tests and `scripts/test-integration.sh` (or `scripts\\test-integration.bat` on Windows) for integration tests. Add a targeted selector such as `--grep` whenever possible. Run `npm run valid-layers-check` only when a change may affect module layering.\n\n## Coding Guidelines\n\n### Markdown\n\n- Do not hard-wrap Markdown prose to a fixed line width. Keep each paragraph on one source line and let the editor or renderer wrap it naturally. Preserve structural line breaks in lists, tables, code blocks, and intentional Markdown hard breaks.\n\n### Indentation\n\nWe use tabs, not spaces.\n\n### Naming Conventions\n\n- Use PascalCase for `type` names\n- Use PascalCase for `enum` values\n- Use camelCase for `function` and `method` names\n- Use camelCase for `property` names and `local variables`\n- Use whole words in names when possible\n\n### Types\n\n- Do not export `types` or `functions` unless you need to share it across multiple components\n- Do not introduce new `types` or `values` to the global namespace\n\n### Comments\n\n- Use JSDoc style comments for `functions`, `interfaces`, `enums`, and `classes`\n\n### Strings\n\n- Use \"double quotes\" for strings shown to the user that need to be externalized (localized)\n- Use 'single quotes' otherwise\n- All strings visible to the user need to be externalized using the `vs/nls` module\n- Externalized strings must not use string concatenation. Use placeholders instead (`{0}`).\n\n### UI labels\n- Use title-style capitalization for command labels, buttons and menu items (each word is capitalized).\n- Don't capitalize prepositions of four or fewer letters unless it's the first or last word (e.g. \"in\", \"with\", \"for\").\n\n### Designing UI\n- When creating, editing, or reviewing any visual surface, reason in **design terms, not pixels**: name the **feeling** (Calm, Focused, Consistent, Delightful), find the **principle** it breaks, then reach for the **move** (token/tier/ramp) that restores it. Describe a bug by its role/tier/ramp (e.g. \"this overlay is rounded at the control tier\"), not its number.\n- See the [`design-philosophy` skill](skills/design-philosophy/SKILL.md) for the full Values→Principles→Moves vocabulary, worked examples, and feedback guidance, and [design-tokens.instructions.md](instructions/design-tokens.instructions.md) for the token reference.\n\n### Style\n\n- Use arrow functions `=>` over anonymous function expressions\n- Only surround arrow function parameters when necessary. For example, `(x) => x + x` is wrong but the following are correct:\n\n```typescript\nx => x + x\n(x, y) => x + y\n<T>(x: T, y: T) => x === y\n```\n\n- Always surround loop and conditional bodies with curly braces\n- Open curly braces always go on the same line as whatever necessitates them\n- Parenthesized constructs should have no surrounding whitespace. A single space follows commas, colons, and semicolons in those constructs. For example:\n\n```typescript\nfor (let i = 0, n = str.length; i < 10; i++) {\n    if (x < 10) {\n        foo();\n    }\n}\nfunction f(x: number, y: string): void { }\n```\n\n- Whenever possible, in top-level scopes, use `export function x(…) {…}` instead of `export const x = (…) => {…}`. One advantage of using the `function` keyword is that the stack trace shows a good name when debugging.\n\n### Code Quality\n\n- All files must include Microsoft copyright header\n- Prefer `async` and `await` over `Promise` and `then` calls\n- All user facing messages must be localized using the applicable localization framework (for example `nls.localize()` method)\n- Don't add tests to the wrong test suite (e.g., adding to end of file instead of inside relevant suite)\n- Look for existing test patterns before creating new structures\n- Use `describe` and `test` consistently with existing patterns\n- Prefer regex capture groups with names over numbered capture groups.\n- If you create any temporary new files, scripts, or helper files for iteration, clean up these files by removing them at the end of the task\n- Never duplicate imports. Always reuse existing imports if they are present.\n- When removing an import, do not leave behind blank lines where the import was. Ensure the surrounding code remains compact.\n- Do not use `any` or `unknown` as the type for variables, parameters, or return values unless absolutely necessary. If they need type annotations, they should have proper types or interfaces defined.\n- When adding file watching, prefer correlated file watchers (via fileService.createWatcher) to shared ones.\n- When adding tooltips to UI elements, prefer the use of IHoverService service.\n- Do not duplicate code. Always look for existing utility functions, helpers, or patterns in the codebase before implementing new functionality. Reuse and extend existing code whenever possible.\n- You MUST deal with disposables by registering them immediately after creation for later disposal. Use helpers such as `DisposableStore`, `MutableDisposable` or `DisposableMap`. Do NOT register a disposable to the containing class if the object is created within a method that is called repeatedly to avoid leaks. Instead, return an `IDisposable` from such method and let the caller register it.\n- You MUST NOT use storage keys of another component only to make changes to that component. You MUST come up with proper API to change another component.\n- Use `IEditorService` to open editors instead of `IEditorGroupsService.activeGroup.openEditor` to ensure that the editor opening logic is properly followed and to avoid bypassing important features such as `revealIfOpened` or `preserveFocus`.\n- Avoid using `bind()`, `call()` and `apply()` solely to control `this` or partially apply arguments; prefer arrow functions or closures to capture the necessary context, and use these methods only when required by an API or interoperability.\n- Avoid using events to drive control flow between components. Instead, prefer direct method calls or service interactions to ensure clearer dependencies and easier traceability of logic. Events should be reserved for broadcasting state changes or notifications rather than orchestrating behavior across components.\n- Service dependencies MUST be declared in constructors and MUST NOT be accessed through the `IInstantiationService` at any other point in time.\n\n## Learnings\n- Minimize the amount of assertions in tests. Prefer one snapshot-style `assert.deepStrictEqual` over multiple precise assertions, as they are much more difficult to understand and to update.\n- Do not stub a global object (e.g. `(mainWindow as any).ResizeObserver = ...`) or use `any` casts to install fakes in tests. Instead, make the dependency injectable: add an optional constructor parameter on the production class that defaults to the real implementation (e.g. `targetWindow.ResizeObserver`), and have the test pass a fake that implements the real interface.\n\n<!-- File: .claude-plugin/marketplace.json (Tokens: ~300 | Category: marketplace) -->\n# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/microsoft/vscode/HEAD/.claude-plugin/marketplace.json)\n\n<!-- File: .claude-plugin/plugin.json (Tokens: ~300 | Category: plugin-manifest) -->\n# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/microsoft/vscode/HEAD/.claude-plugin/plugin.json)\n\n<!-- File: .cursor/mcp.json (Tokens: ~300 | Category: mcp-config) -->\n# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/microsoft/vscode/HEAD/.cursor/mcp.json)\n\n<!-- File: .cursorrules (vscode-extension-dev-typescript-cursorrules-prompt-file.mdc) (Tokens: ~969 | Category: cursor-rule) -->\n---\ndescription: \"Cursor rules for Vscode Extension Dev Typescript.\"\nglobs: **/*\nalwaysApply: false\n---\nYou are an expert in VSCode Extension Development, TypeScript, Node.js, HTML, CSS, VSCode APIs, and Electron.\n\nCode Style and Structure:\n- Write clear, concise TypeScript code following modern ECMAScript standards.\n- Use modular design patterns to separate concerns (e.g., separate commands, UI components, and business logic).\n- Organize your project into meaningful directories such as src, out, and assets.\n- Include comprehensive inline comments and JSDoc annotations for public APIs.\n\nNaming Conventions:\n- Use kebab-case for file and folder names (e.g., my-extension, command-handler.ts).\n- Use camelCase for variables and function names.\n- Use PascalCase for classes and interfaces.\n- Name commands and configuration keys descriptively (e.g., 'extension.activateFeature', 'extension.showOutput').\n\nTypeScript Usage:\n- Leverage TypeScript for static type checking and enhanced developer experience.\n- Use interfaces and types to define extension commands, configuration schemas, and message payloads.\n- Utilize generics, union types, and type guards to create robust and flexible APIs.\n- Configure strict type checking in tsconfig.json to catch potential errors early.\n\nExtension Architecture:\n- Follow the VSCode Extension API guidelines to structure your extension entry point (typically in extension.ts).\n- Register commands, events, and providers within the activate() function.\n- Use dependency injection where possible to manage state and service interactions.\n- Modularize features into separate files or modules to improve maintainability.\n\nManifest (package.json) and Configuration:\n- Define extension metadata, activation events, contributions (commands, menus, keybindings), and configuration in package.json.\n- Follow VSCode’s schema for extension manifests to ensure compatibility and discoverability.\n- Use activation events wisely to minimize performance overhead (e.g., onCommand, onLanguage).\n- Document all configurable options clearly in package.json and corresponding README files.\n\nSecurity and Privacy:\n- Adhere to the principle of least privilege; request only the permissions you need.\n- Validate and sanitize any input or configuration data.\n- Avoid exposing sensitive APIs or secrets within the extension.\n- Implement error handling and logging that do not leak internal state information.\n\nUI and Styling:\n- Use VSCode’s Webview API for custom UIs when necessary; otherwise, leverage the built-in VSCode UI components.\n- Maintain consistency with the VSCode design language to provide a seamless user experience.\n- Use responsive design principles to support different screen sizes and themes (dark/light modes).\n- Structure HTML, CSS, and JavaScript/TypeScript in a way that separates concerns and supports maintainability.\n\nPerformance Optimization:\n- Optimize extension activation by deferring non-critical operations until after activation.\n- Use asynchronous programming (async/await, Promises) to avoid blocking the main thread.\n- Profile and monitor resource usage; consider lazy-loading features to reduce initial load time.\n- Avoid unnecessary file system or network operations during activation.\n\nVSCode API Usage:\n- Familiarize yourself with the official VSCode API and follow its guidelines for registering commands, creating status bar items, handling events, etc.\n- Use vscode.workspace, vscode.window, and vscode.commands to interact with the editor efficiently.\n- Always handle potential errors when calling VSCode APIs to improve extension resilience.\n- Keep up to date with the latest VSCode API changes and deprecations.\n\nCross-platform Compatibility:\n- Ensure your extension works seamlessly across Windows, macOS, and Linux.\n- Test on different environments to identify any OS-specific issues.\n- Use Node.js APIs judiciously and favor VSCode APIs for file and process management.\n\nTesting and Debugging:\n- Write unit tests for core functionality using testing frameworks like Mocha or Jest.\n- Use the VSCode Extension Test Runner for integration tests.\n- Leverage VSCode’s built-in debugging tools to set breakpoints and inspect runtime behavior.\n- Incorporate logging with appropriate levels (info, warn, error) to aid in troubleshooting.\n\nContext-Aware Development:\n- Consider the full project context when integrating new features; ensure consistency with existing functionality.\n- Avoid duplicating code and ensure new components interact seamlessly with current ones.\n- Review user feedback and extension telemetry to continuously refine and optimize your extension.\n- When providing code snippets or solutions, ensure they align with the established project architecture and coding standards.\n\nCode Output:\n- Provide full file contents when sharing code examples to ensure completeness and clarity.\n- Include all necessary imports, module declarations, and surrounding code context.\n- Clearly comment on significant changes or additions to explain the rationale behind decisions.\n- When code snippets are too long, indicate where the snippet fits into the overall project structure.\n\nFollow the official VSCode Extension documentation for best practices, API usage, and security guidelines.\n</yakaai_skills>"}