[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6FKZQPMA7VRA0PRBZRDFJTX":3,"skill-same:01M6FKZQPMA7VRA0PRBZRDFJTX":80},{"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":31,"publishedAt":51,"linkOnly":52,"markdownContent":53,"markdownBody":54,"frontMatter":55,"refName":56,"commitSha":57,"skillDirectory":58,"forksCount":59,"repositoryHtmlUrl":60,"repositoryHomepageUrl":61,"ownerHtmlUrl":62,"ownerBlogUrl":63,"ownerDescription":64,"updatedAt":65,"install":66,"resources":79},"01M6FKZQPMA7VRA0PRBZRDFJTX","vscode-extension",null,"Use when investigating, developing, debugging, testing, or reviewing Aspire VS Code extension behavior under extension\u002F, including extension UI, command, debugger, RPC, DCP, MCP, and CLI-integration issues or features.","microsoft\u002Faspire","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M6FKTZ7ND1S9JN6JTVK7A7MD",6417,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fvscode-extension\u002FSKILL.md",[18,23,26],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50],"vscode","extension","vscode extension","ui","when","features","use","behavior","command","debugger","integration","testing","rpc","issues","code","debugging","aspire","cli","MCP","2026-11-10 10:12:30",false,"---\nname: vscode-extension\ndescription: \"Use when investigating, developing, debugging, testing, or reviewing Aspire VS Code extension behavior under extension\u002F, including extension UI, command, debugger, RPC, DCP, MCP, and CLI-integration issues or features.\"\n---\n\n# Aspire VS Code Extension\n\nThis skill covers working on the Aspire VS Code extension, which lives entirely under\n[extension\u002F](..\u002F..\u002F..\u002Fextension). It is a TypeScript extension built with **yarn** (pinned via\n`packageManager` in `extension\u002Fpackage.json`) and **webpack**, and it communicates with the Aspire\nCLI over RPC.\n\n## Orientation\n\nAll commands below are run from the `extension\u002F` directory unless noted.\n\n| Path | What it is |\n|------|------------|\n| `extension\u002Fsrc\u002Fextension.ts` | Activation entry point |\n| `extension\u002Fsrc\u002Fcommands\u002F` | Command implementations |\n| `extension\u002Fsrc\u002Fviews\u002F` | Tree views, welcome views, panel UI |\n| `extension\u002Fsrc\u002Fdebugger\u002F` | Debug adapter + per-language debuggers (dotnet, node, python, go) |\n| `extension\u002Fsrc\u002Fserver\u002F`, `extension\u002Fsrc\u002Fmcp\u002F`, `extension\u002Fsrc\u002Fdcp\u002F` | RPC server, MCP provider, DCP integration |\n| `extension\u002Fsrc\u002Floc\u002Fstrings.ts` | Localized strings (TypeScript-side) |\n| `extension\u002Fpackage.nls.json` | Localized strings referenced from `package.json` (`%key%`) |\n| `extension\u002Fsrc\u002Ftest\u002F` | Mocha unit tests (`*.test.ts`) run via `vscode-test` |\n| `extension\u002Fpackage.json` | Manifest: `contributes`, `activationEvents`, scripts |\n\n## Prerequisites\n\n**Do NOT run the repo-root `.\u002Fbuild.sh` when you are only working on the Aspire CLI and\u002For the VS\nCode extension.** The root build compiles the entire product (all of `src\u002F`, native AOT, packages)\nand is slow and unnecessary for this work. Root restore is needed only to bootstrap the repository's\n.NET SDK. Check the SDK from the repository root:\n\n- If `.\u002F.dotnet\u002Fdotnet --version` (Linux\u002FmacOS) or `.\\.dotnet\\dotnet.exe --version` (Windows)\n  succeeds, add `.dotnet` to `PATH` (`export PATH=\"$PWD\u002F.dotnet:$PATH\"` on Linux\u002FmacOS or\n  `$env:PATH = \"$PWD\\.dotnet;$env:PATH\"` in PowerShell) and skip root restore.\n- Otherwise, if `dotnet --version` succeeds, skip root restore and use that host.\n- If neither succeeds, run `.\u002Frestore.sh` (Linux\u002FmacOS) or `.\\restore.cmd` (Windows) once, then add\n  the installed `.dotnet` directory to `PATH` as shown above.\n\nThe extension build script does not install .NET.\n\nOnce the required SDK is available, **build the extension and CLI together with the extension build\nscript.** From `extension\u002F`, run `.\u002Fbuild.sh` (Linux\u002FmacOS) or `.\u002Fbuild.ps1` (Windows). This script builds the Aspire CLI\n(`dotnet build ..\u002Fsrc\u002FAspire.Cli\u002FAspire.Cli.csproj`) **and** the extension, and installs extension\ndependencies (seeds Corepack and runs `corepack yarn install`). You do not install Yarn yourself —\nit is pinned via `packageManager`.\n\nFor changes limited to `extension\u002F`, `src\u002FAspire.Cli\u002F`, and\u002For `tests\u002FAspire.Cli*\u002F`, start with the\nextension build script once either SDK check succeeds. It performs the project restore and build\nsteps needed by this workflow. Run targeted CLI test projects separately after the build.\n\nUse **yarn** for extension commands (`corepack yarn ...` or `yarn run ...`), not `npm` \u002F `npx`.\nThe dependency graph and scripts are pinned for Yarn via `extension\u002Fpackage.json` and `yarn.lock`.\n\nIf `corepack yarn install` fails with registry 401\u002F404 or `EACCES`, see the Troubleshooting section\nof [extension\u002FCONTRIBUTING.md](..\u002F..\u002F..\u002Fextension\u002FCONTRIBUTING.md) — these are environment\u002Fnpm-mirror\nissues, not code issues.\n\n## Extension ↔ CLI compatibility (IMPORTANT)\n\nThe extension and the Aspire CLI are tightly coupled: **new features or changes in the extension\noften require corresponding changes in the CLI.** When you add or modify extension behavior, expect\nto also touch `src\u002FAspire.Cli\u002F` and rebuild both with `extension\u002Fbuild.sh` \u002F `extension\u002Fbuild.ps1`.\n\nWhen you change a CLI contract or expectation (command output shape, JSON schema, new flags, new\nbehavior the extension relies on), **you must remain backwards compatible and keep working with older\nAspire CLI versions.** A user may have a newer extension paired with an older `aspire` CLI on their\nPATH. Do not assume the CLI supports a capability just because the current build does.\n\nDetect what the installed CLI supports at runtime instead of assuming, by reading capabilities from extension functionality that wraps `aspire config info`.\n\nHidden or probe-style CLI calls from the extension should avoid paying for or emitting interactive\nstartup UX. When the extension runs a CLI command for JSON or other machine-readable output, pass\n`--nologo` when the target CLI version supports it, keep the command's stdout parseable, and add a\nfallback\u002Fretry path for older CLIs that reject `--nologo`. Add or update CLI-side machine-readable\ndetection if you introduce a new structured-output flag or hidden JSON command. This prevents\nfirst-run\u002Fbanner\u002Fidentity text from corrupting stdout and keeps extension startup comparable to\ndirect `aspire run` \u002F `aspire start`.\n\n## Develop \u002F modify the extension\n\n- Prefer **TypeScript** (`.ts`) files; never create `.js` source files for extension code.\n- Use **static imports**, not dynamic imports, unless dynamic import is absolutely necessary.\n- Use the latest TypeScript features consistent with the existing code style.\n- New user-facing commands, views, settings, or debugger config go in the `contributes` section of\n  `extension\u002Fpackage.json`.\n\n### Localization (REQUIRED for any user-facing string)\n\nEvery string shown to the user must be localized. There are two surfaces:\n\n- **TypeScript code** → add to `extension\u002Fsrc\u002Floc\u002Fstrings.ts` using `vscode.l10n.t(...)`. Follow the\n  existing pattern (plain `const` for static strings, an arrow function for strings with\n  placeholders like `{0}`). Import from `loc\u002Fstrings` rather than inlining literals.\n- **`package.json` manifest** (command titles, view names, setting descriptions, debugger\n  properties) → use a `%key%` reference and define the key in `extension\u002Fpackage.nls.json`.\n\nDo not hand-edit generated localization bundles (the `l10n\u002F` output, `*.xlf`, or\n`*\u002Flocalize\u002Ftemplatestrings.*.json`); translation is handled by a dedicated workflow. The npm\nscripts `l10n:export` \u002F `l10n:import` (run automatically by `precompile`\u002F`prepackage`\u002F`prewatch`)\nregenerate the l10n bundle from `package.nls.json` and the `vscode.l10n.t` calls.\n\n## Build\n\nFrom `extension\u002F`:\n\n```bash\nyarn run compile      # one-off webpack build to .\u002Fdist\nyarn run watch        # incremental webpack build (use while iterating)\nyarn run package      # production build (minified, hidden source maps)\n```\n\n`watch`, `compile`, and `package` are preceded by `prewatch`\u002F`precompile`\u002F`prepackage`, which run\n`generate-version`, `generate-schema`, and the l10n export\u002Fimport. The VS Code task\n`yarn: watch extension` (the default build task) runs `yarn run watch`.\n\nTo produce a `.vsix`, the full MSBuild path is `extension\u002FExtension.proj` (used by CI\u002Fsigning); for\nlocal iteration `yarn run package` plus the launch configs below is usually enough.\n\n## Test\n\nThe extension has Mocha unit tests under `extension\u002Fsrc\u002Ftest\u002F` executed by `@vscode\u002Ftest-cli`.\n\n```bash\nyarn run compile-tests   # tsc -> .\u002Fout (or watch-tests to keep rebuilding)\nyarn run test            # alias for unit-test (vscode-test); runs lint+compile via pretest\nyarn run lint            # eslint src\n```\n\n`pretest` runs `compile-tests`, `compile`, and `lint`, so `yarn run test` is the single command that\nbuilds and runs everything. When iterating on one area, keep `watch-tests` running and re-run\n`yarn run test`.\n\nAdd new tests as `extension\u002Fsrc\u002Ftest\u002F\u003Carea>.test.ts` mirroring nearby tests (e.g.\n`appHostDiscovery.test.ts`, `strings.test.ts`). There is a `strings.test.ts` that guards\nlocalization conventions — run it after touching `loc\u002Fstrings.ts` or `package.nls.json`.\n\nWhen adding, changing, or investigating user-visible UI behavior or interactions, strongly prefer\nadding or updating VS Code extension E2E coverage under `extension\u002Fsrc\u002Ftest-e2e\u002F` so the behavior is\nreproducible and protected from regressions. Skip this only with a strong, explicit justification.\nIf you run these tests against an older published CLI for compatibility validation, set\n`ASPIRE_EXTENSION_E2E_SKIP_CURRENT_CLI_REGRESSIONS=true` to skip tests that intentionally cover bugs\nfixed only by the current repo-built CLI.\n\n## Debug \u002F run locally\n\n1. Open the `extension\u002F` folder in VS Code.\n2. Launch the **Run Extension** launch configuration to start an Extension Development Host, or\n   **Run Extension (cli stop on entry)** to make the CLI wait for a debugger to attach (use this to\n   debug the CLI and the extension together).\n3. To debug against a locally built CLI, set the `Aspire Cli Executable Path` setting to the build\n   output, e.g. `artifacts\u002Fbin\u002FAspire.Cli\u002FDebug\u002Fnet11.0\u002Faspire` (relative to the repo root). The\n   `Aspire: Extension settings` command opens settings filtered to the extension.\n\nRPC and debugger issues usually live in `src\u002Fserver\u002F`, `src\u002Fdebugger\u002F`, or `src\u002Fdcp\u002F`.\n\n## Reproducing issues yourself (do this FIRST for root-cause \u002F \"can you repro\" requests)\n\nWhen asked to **find the root cause of** or **reproduce** an issue, do not stop at reading source\ncode. Strongly prefer a reproducible VS Code extension E2E test under `extension\u002Fsrc\u002Ftest-e2e\u002F` that\nopens a workspace, drives the extension through its public UI\u002Fcommands, and captures the failing\nbehavior in the E2E state file, VS Code logs, screenshots, or assertions.\n\nUse Playwright or an Extension Development Host only as exploratory help when the right E2E shape is\nnot yet clear. If that exploration reproduces the issue, convert the scenario into an E2E test before\nfixing the bug unless there is a strong, explicit reason not to. You can test a custom CLI build by\npointing the `Aspire Cli Executable Path` setting at your locally built `aspire`.\n\n## Pull request evidence\n\nWhen opening a PR for a user-visible VS Code extension change, include proof in the PR body. Prefer\nbefore\u002Fafter screenshots for changed UI, notifications, tree views, browser flows, or error states.\nIf you include a before screenshot, include an actual after screenshot of the changed state too;\nfocused tests, E2E state files, logs, or command output can support the after case, but they are not\na substitute for the after visual. Include a short video or recording when the behavior is\ninteractive, timing-sensitive, or difficult to understand from static images. If screenshots or video\nare not appropriate, say why and include the closest useful evidence instead. Redact tokens, secrets,\nlocal usernames, private paths, private URLs, and any other sensitive details before putting evidence\nin a public PR body.\n\n## Gotchas\n\n- Do not modify `package.json` \u002F `yarn.lock` \u002F `package-lock.json` unless explicitly asked; when you\n  must pin a transitive dependency, add it to `resolutions` and regenerate `yarn.lock` with\n  `corepack yarn install` (see CONTRIBUTING).\n- `yarn.lock` must resolve through the internal `dotnet-public-npm` feed; the build rejects public\n  npmjs.org URLs.\n- Generated files (`l10n\u002F` bundle, schema, version) are produced by the pre-scripts — edit the\n  sources (`package.nls.json`, `loc\u002Fstrings.ts`, schema\u002Fversion generator scripts), not the output.\n","# Aspire VS Code Extension\n\nThis skill covers working on the Aspire VS Code extension, which lives entirely under\n[extension\u002F](..\u002F..\u002F..\u002Fextension). It is a TypeScript extension built with **yarn** (pinned via\n`packageManager` in `extension\u002Fpackage.json`) and **webpack**, and it communicates with the Aspire\nCLI over RPC.\n\n## Orientation\n\nAll commands below are run from the `extension\u002F` directory unless noted.\n\n| Path | What it is |\n|------|------------|\n| `extension\u002Fsrc\u002Fextension.ts` | Activation entry point |\n| `extension\u002Fsrc\u002Fcommands\u002F` | Command implementations |\n| `extension\u002Fsrc\u002Fviews\u002F` | Tree views, welcome views, panel UI |\n| `extension\u002Fsrc\u002Fdebugger\u002F` | Debug adapter + per-language debuggers (dotnet, node, python, go) |\n| `extension\u002Fsrc\u002Fserver\u002F`, `extension\u002Fsrc\u002Fmcp\u002F`, `extension\u002Fsrc\u002Fdcp\u002F` | RPC server, MCP provider, DCP integration |\n| `extension\u002Fsrc\u002Floc\u002Fstrings.ts` | Localized strings (TypeScript-side) |\n| `extension\u002Fpackage.nls.json` | Localized strings referenced from `package.json` (`%key%`) |\n| `extension\u002Fsrc\u002Ftest\u002F` | Mocha unit tests (`*.test.ts`) run via `vscode-test` |\n| `extension\u002Fpackage.json` | Manifest: `contributes`, `activationEvents`, scripts |\n\n## Prerequisites\n\n**Do NOT run the repo-root `.\u002Fbuild.sh` when you are only working on the Aspire CLI and\u002For the VS\nCode extension.** The root build compiles the entire product (all of `src\u002F`, native AOT, packages)\nand is slow and unnecessary for this work. Root restore is needed only to bootstrap the repository's\n.NET SDK. Check the SDK from the repository root:\n\n- If `.\u002F.dotnet\u002Fdotnet --version` (Linux\u002FmacOS) or `.\\.dotnet\\dotnet.exe --version` (Windows)\n  succeeds, add `.dotnet` to `PATH` (`export PATH=\"$PWD\u002F.dotnet:$PATH\"` on Linux\u002FmacOS or\n  `$env:PATH = \"$PWD\\.dotnet;$env:PATH\"` in PowerShell) and skip root restore.\n- Otherwise, if `dotnet --version` succeeds, skip root restore and use that host.\n- If neither succeeds, run `.\u002Frestore.sh` (Linux\u002FmacOS) or `.\\restore.cmd` (Windows) once, then add\n  the installed `.dotnet` directory to `PATH` as shown above.\n\nThe extension build script does not install .NET.\n\nOnce the required SDK is available, **build the extension and CLI together with the extension build\nscript.** From `extension\u002F`, run `.\u002Fbuild.sh` (Linux\u002FmacOS) or `.\u002Fbuild.ps1` (Windows). This script builds the Aspire CLI\n(`dotnet build ..\u002Fsrc\u002FAspire.Cli\u002FAspire.Cli.csproj`) **and** the extension, and installs extension\ndependencies (seeds Corepack and runs `corepack yarn install`). You do not install Yarn yourself —\nit is pinned via `packageManager`.\n\nFor changes limited to `extension\u002F`, `src\u002FAspire.Cli\u002F`, and\u002For `tests\u002FAspire.Cli*\u002F`, start with the\nextension build script once either SDK check succeeds. It performs the project restore and build\nsteps needed by this workflow. Run targeted CLI test projects separately after the build.\n\nUse **yarn** for extension commands (`corepack yarn ...` or `yarn run ...`), not `npm` \u002F `npx`.\nThe dependency graph and scripts are pinned for Yarn via `extension\u002Fpackage.json` and `yarn.lock`.\n\nIf `corepack yarn install` fails with registry 401\u002F404 or `EACCES`, see the Troubleshooting section\nof [extension\u002FCONTRIBUTING.md](..\u002F..\u002F..\u002Fextension\u002FCONTRIBUTING.md) — these are environment\u002Fnpm-mirror\nissues, not code issues.\n\n## Extension ↔ CLI compatibility (IMPORTANT)\n\nThe extension and the Aspire CLI are tightly coupled: **new features or changes in the extension\noften require corresponding changes in the CLI.** When you add or modify extension behavior, expect\nto also touch `src\u002FAspire.Cli\u002F` and rebuild both with `extension\u002Fbuild.sh` \u002F `extension\u002Fbuild.ps1`.\n\nWhen you change a CLI contract or expectation (command output shape, JSON schema, new flags, new\nbehavior the extension relies on), **you must remain backwards compatible and keep working with older\nAspire CLI versions.** A user may have a newer extension paired with an older `aspire` CLI on their\nPATH. Do not assume the CLI supports a capability just because the current build does.\n\nDetect what the installed CLI supports at runtime instead of assuming, by reading capabilities from extension functionality that wraps `aspire config info`.\n\nHidden or probe-style CLI calls from the extension should avoid paying for or emitting interactive\nstartup UX. When the extension runs a CLI command for JSON or other machine-readable output, pass\n`--nologo` when the target CLI version supports it, keep the command's stdout parseable, and add a\nfallback\u002Fretry path for older CLIs that reject `--nologo`. Add or update CLI-side machine-readable\ndetection if you introduce a new structured-output flag or hidden JSON command. This prevents\nfirst-run\u002Fbanner\u002Fidentity text from corrupting stdout and keeps extension startup comparable to\ndirect `aspire run` \u002F `aspire start`.\n\n## Develop \u002F modify the extension\n\n- Prefer **TypeScript** (`.ts`) files; never create `.js` source files for extension code.\n- Use **static imports**, not dynamic imports, unless dynamic import is absolutely necessary.\n- Use the latest TypeScript features consistent with the existing code style.\n- New user-facing commands, views, settings, or debugger config go in the `contributes` section of\n  `extension\u002Fpackage.json`.\n\n### Localization (REQUIRED for any user-facing string)\n\nEvery string shown to the user must be localized. There are two surfaces:\n\n- **TypeScript code** → add to `extension\u002Fsrc\u002Floc\u002Fstrings.ts` using `vscode.l10n.t(...)`. Follow the\n  existing pattern (plain `const` for static strings, an arrow function for strings with\n  placeholders like `{0}`). Import from `loc\u002Fstrings` rather than inlining literals.\n- **`package.json` manifest** (command titles, view names, setting descriptions, debugger\n  properties) → use a `%key%` reference and define the key in `extension\u002Fpackage.nls.json`.\n\nDo not hand-edit generated localization bundles (the `l10n\u002F` output, `*.xlf`, or\n`*\u002Flocalize\u002Ftemplatestrings.*.json`); translation is handled by a dedicated workflow. The npm\nscripts `l10n:export` \u002F `l10n:import` (run automatically by `precompile`\u002F`prepackage`\u002F`prewatch`)\nregenerate the l10n bundle from `package.nls.json` and the `vscode.l10n.t` calls.\n\n## Build\n\nFrom `extension\u002F`:\n\n```bash\nyarn run compile      # one-off webpack build to .\u002Fdist\nyarn run watch        # incremental webpack build (use while iterating)\nyarn run package      # production build (minified, hidden source maps)\n```\n\n`watch`, `compile`, and `package` are preceded by `prewatch`\u002F`precompile`\u002F`prepackage`, which run\n`generate-version`, `generate-schema`, and the l10n export\u002Fimport. The VS Code task\n`yarn: watch extension` (the default build task) runs `yarn run watch`.\n\nTo produce a `.vsix`, the full MSBuild path is `extension\u002FExtension.proj` (used by CI\u002Fsigning); for\nlocal iteration `yarn run package` plus the launch configs below is usually enough.\n\n## Test\n\nThe extension has Mocha unit tests under `extension\u002Fsrc\u002Ftest\u002F` executed by `@vscode\u002Ftest-cli`.\n\n```bash\nyarn run compile-tests   # tsc -> .\u002Fout (or watch-tests to keep rebuilding)\nyarn run test            # alias for unit-test (vscode-test); runs lint+compile via pretest\nyarn run lint            # eslint src\n```\n\n`pretest` runs `compile-tests`, `compile`, and `lint`, so `yarn run test` is the single command that\nbuilds and runs everything. When iterating on one area, keep `watch-tests` running and re-run\n`yarn run test`.\n\nAdd new tests as `extension\u002Fsrc\u002Ftest\u002F\u003Carea>.test.ts` mirroring nearby tests (e.g.\n`appHostDiscovery.test.ts`, `strings.test.ts`). There is a `strings.test.ts` that guards\nlocalization conventions — run it after touching `loc\u002Fstrings.ts` or `package.nls.json`.\n\nWhen adding, changing, or investigating user-visible UI behavior or interactions, strongly prefer\nadding or updating VS Code extension E2E coverage under `extension\u002Fsrc\u002Ftest-e2e\u002F` so the behavior is\nreproducible and protected from regressions. Skip this only with a strong, explicit justification.\nIf you run these tests against an older published CLI for compatibility validation, set\n`ASPIRE_EXTENSION_E2E_SKIP_CURRENT_CLI_REGRESSIONS=true` to skip tests that intentionally cover bugs\nfixed only by the current repo-built CLI.\n\n## Debug \u002F run locally\n\n1. Open the `extension\u002F` folder in VS Code.\n2. Launch the **Run Extension** launch configuration to start an Extension Development Host, or\n   **Run Extension (cli stop on entry)** to make the CLI wait for a debugger to attach (use this to\n   debug the CLI and the extension together).\n3. To debug against a locally built CLI, set the `Aspire Cli Executable Path` setting to the build\n   output, e.g. `artifacts\u002Fbin\u002FAspire.Cli\u002FDebug\u002Fnet11.0\u002Faspire` (relative to the repo root). The\n   `Aspire: Extension settings` command opens settings filtered to the extension.\n\nRPC and debugger issues usually live in `src\u002Fserver\u002F`, `src\u002Fdebugger\u002F`, or `src\u002Fdcp\u002F`.\n\n## Reproducing issues yourself (do this FIRST for root-cause \u002F \"can you repro\" requests)\n\nWhen asked to **find the root cause of** or **reproduce** an issue, do not stop at reading source\ncode. Strongly prefer a reproducible VS Code extension E2E test under `extension\u002Fsrc\u002Ftest-e2e\u002F` that\nopens a workspace, drives the extension through its public UI\u002Fcommands, and captures the failing\nbehavior in the E2E state file, VS Code logs, screenshots, or assertions.\n\nUse Playwright or an Extension Development Host only as exploratory help when the right E2E shape is\nnot yet clear. If that exploration reproduces the issue, convert the scenario into an E2E test before\nfixing the bug unless there is a strong, explicit reason not to. You can test a custom CLI build by\npointing the `Aspire Cli Executable Path` setting at your locally built `aspire`.\n\n## Pull request evidence\n\nWhen opening a PR for a user-visible VS Code extension change, include proof in the PR body. Prefer\nbefore\u002Fafter screenshots for changed UI, notifications, tree views, browser flows, or error states.\nIf you include a before screenshot, include an actual after screenshot of the changed state too;\nfocused tests, E2E state files, logs, or command output can support the after case, but they are not\na substitute for the after visual. Include a short video or recording when the behavior is\ninteractive, timing-sensitive, or difficult to understand from static images. If screenshots or video\nare not appropriate, say why and include the closest useful evidence instead. Redact tokens, secrets,\nlocal usernames, private paths, private URLs, and any other sensitive details before putting evidence\nin a public PR body.\n\n## Gotchas\n\n- Do not modify `package.json` \u002F `yarn.lock` \u002F `package-lock.json` unless explicitly asked; when you\n  must pin a transitive dependency, add it to `resolutions` and regenerate `yarn.lock` with\n  `corepack yarn install` (see CONTRIBUTING).\n- `yarn.lock` must resolve through the internal `dotnet-public-npm` feed; the build rejects public\n  npmjs.org URLs.\n- Generated files (`l10n\u002F` bundle, schema, version) are produced by the pre-scripts — edit the\n  sources (`package.nls.json`, `loc\u002Fstrings.ts`, schema\u002Fversion generator scripts), not the output.\n",{"name":5,"description":7},"main","cec61ac9b795bbfd9913f0c7196689b0d7a215d7",".agents\u002Fskills\u002Fvscode-extension",1040,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire","https:\u002F\u002Faspire.dev","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-11-12 04:16:48",{"source":8,"skillName":5,"commands":67,"prompt":77,"zipAvailable":78},[68,71,74],{"tool":69,"command":70},"npx","npx skills add microsoft\u002Faspire --skill vscode-extension",{"tool":72,"command":73},"bunx","bunx skills add microsoft\u002Faspire --skill vscode-extension",{"tool":75,"command":76},"pnpm","pnpm dlx skills add microsoft\u002Faspire --skill vscode-extension","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fvscode-extension\u002FSKILL.md",true,[],[81,106,119,137,163,189],{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":90,"publishedAt":51},"01M6FKZJG81XP80SVWFBJVMDWN","update-container-images","Updates Docker container image tags used by Aspire hosting integrations. Queries registries for newer tags, uses LLM to determine version-compatible updates, and applies changes. Use this when asked to update container image versions.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fupdate-container-images\u002FSKILL.md",[87],{"categoryNo":88,"categoryName":89,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",[91,92,93,94,95,96,97,48,98,38,99,100,101,102,103,104,105,36],"container images","update","container","images","update container images","image","docker","integrations","version","hosting","queries","tags","updates","for","changes",{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":113,"publishedAt":51},"01M6FKZDY1MY0QA62EYSDG5NHW","test-management","Quarantines or disables flaky\u002Fproblematic tests using the QuarantineTools utility","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Ftest-management\u002FSKILL.md",[112],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[114,115,116,117,118],"test","management","test management","tests","utility",{"skillNo":120,"name":121,"nameZh":6,"description":122,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":123,"categories":124,"keywords":125,"publishedAt":51},"01M6FKZAQ428JX8F6NSA19XBQJ","startup-perf","Measures Aspire startup profiling with CLI self-profile capture and dashboard export traces.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fstartup-perf\u002FSKILL.md",[],[126,127,128,49,129,48,130,131,132,133,134,135,136],"perf","startup","startup perf","dashboard","profiling","capture","profile","export","self","with","traces",{"skillNo":138,"name":139,"nameZh":6,"description":140,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":141,"categories":142,"keywords":143,"publishedAt":51},"01M6FKZ4W4J0ET0Q0C2Z30HYRV","reviewing-aspire-architecture","Use only when the user explicitly requests a deep Aspire architectural or pattern review of an existing PR or diff, or when a generic reviewer escalates a named Aspire-domain question it cannot resolve. Do not use for ordinary review, implementation, debugging, explanation, or design discussion—even when a PR is referenced—and never select it from changed file paths alone.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Freviewing-aspire-architecture\u002FSKILL.md",[],[144,48,145,146,147,148,47,149,150,151,152,38,153,154,155,156,157,158,159,160,104,161,162,36],"architecture","reviewing aspire architecture","design","review","pr","file","select","reviewer","question","diff","never","only","do","domain","pattern","deep","paths","Existing","generic",{"skillNo":164,"name":165,"nameZh":6,"description":166,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":167,"categories":168,"keywords":170,"publishedAt":51},"01M6FKYZ44BEPJNV8VQ0X73CZR","pr-testing","Use when asked to test a microsoft\u002Faspire pull request, including CLI, hosting, dashboard, component, template, and VS Code extension changes. Also covers testing PRs that change CI infrastructure — GitHub Actions (workflows, actions, gh-aw agentic workflows, CI scripts under .github\u002F and eng\u002F) and Azure DevOps pipelines (eng\u002Fpipelines, eng\u002Fcommon).","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fpr-testing\u002FSKILL.md",[169],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[43,148,171,49,172,173,129,174,175,176,177,178,48,179,46,180,181,182,183,184,38,185,100,186,33,187,105,188],"pr testing","github","agentic","workflows","change","component","agentic workflows","azure devops","infrastructure","actions","ci","github actions","template","common","devops","pipelines","scripts","prs",{"skillNo":190,"name":191,"nameZh":6,"description":192,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":193,"categories":194,"keywords":195,"publishedAt":51},"01M6FKYST0J8GSYXBHH9X77XFR","issue-investigation","Investigates GitHub issues in microsoft\u002Faspire by gathering issue context, routing to specialized skills, preparing the right reproduction environment, reproducing behavior, and drafting evidence-backed findings or insufficient-info comments for user approval. Use when asked to investigate, reproduce, validate, debug, triage, or root-cause an Aspire issue.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fissue-investigation\u002FSKILL.md",[],[196,197,198,172,199,9,200,201,48,202,203,45,204,205,206,39,207,38,208,209,210,211,104,36,212],"investigation","issue","issue investigation","triage","validate","debug","routing","github issues","investigate","specialized","context","environment","evidence","root-cause","info","comments","drafting"]