[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M69BS66B19C61MP2BT5P77CS":3,"skill-same:01M69BS66B19C61MP2BT5P77CS":74},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":46,"linkOnly":47,"markdownContent":48,"markdownBody":49,"frontMatter":50,"refName":51,"commitSha":52,"skillDirectory":53,"forksCount":54,"repositoryHtmlUrl":55,"repositoryHomepageUrl":6,"ownerHtmlUrl":56,"ownerBlogUrl":57,"ownerDescription":58,"updatedAt":59,"install":60,"resources":73},"01M69BS66B19C61MP2BT5P77CS","error-translation",null,"How infrastructure-caused database failures are turned into messages users can act on, via ErrorExplanationService. Use when adding a discovery plugin, a connection source, a reachability provider, a new tree view or webview surface, when a user reports a confusing or raw driver error, or when asked to improve error messages for Docker, Kubernetes, Atlas, Azure or any other infrastructure-backed connection.","microsoft\u002Fvscode-documentdb","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M69BRX0BQJ0QGRNCNZAAAXBV",33,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode-documentdb\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ferror-translation\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45],"error","translation","error translation","for","can","atlas","when","database","use","new","improve","messages","discovery","provider","error messages","view","tree","kubernetes","infrastructure","docker","plugin","azure","2026-11-10 10:12:30",false,"---\nname: error-translation\ndescription: How infrastructure-caused database failures are turned into messages users can act on, via ErrorExplanationService. Use when adding a discovery plugin, a connection source, a reachability provider, a new tree view or webview surface, when a user reports a confusing or raw driver error, or when asked to improve error messages for Docker, Kubernetes, Atlas, Azure or any other infrastructure-backed connection.\n---\n\n# Error Translation\n\nA connection can fail for reasons that have nothing to do with the database: a container was\nstopped, a port-forward tunnel died, a service closed the TLS handshake. The driver reports these\nas `ECONNREFUSED`, a server-selection timeout, or an OpenSSL alert, none of which tell the user\nwhat to do.\n\n`ErrorExplanationService` lets the source that owns the infrastructure explain the failure in\nits own words.\n\n## The one rule\n\n> **Providers translate. They never show UI and never recover.**\n\nNo dialogs, no notifications, no progress bars, no starting or restarting anything, no retries, no\nprompts. A provider receives an error and returns text.\n\nThis is not a style preference. One user action often runs several database commands, several\nactions can fail at the same time, and many calls happen on background paths that show nothing. A\nprovider that showed UI or repaired state would produce duplicate dialogs, dialogs nobody asked\nfor, and errors that are already obsolete by the time they appear.\n\nAnything with a side effect belongs at the call site, which alone knows whether the user is\nwatching, whether the operation was a read or a write, and which surface is right.\n\n## Adding a provider\n\nImplement `ErrorExplanationProvider` and register it in\n[ClustersExtension.registerDiscoveryServices](..\u002F..\u002F..\u002Fsrc\u002Fdocumentdb\u002FClustersExtension.ts),\nnext to the existing ones.\n\n```ts\nexport class MyErrorExplainer implements ErrorExplanationProvider {\n    public readonly id = 'my-source';\n\n    public async explain({ clusterId, error }: ErrorExplanationRequest): Promise\u003Cstring | undefined> {\n        if (!isMine(clusterId)) {\n            return undefined; \u002F\u002F not ours: the caller shows the original error\n        }\n        if (!looksLikeMyFailure(error)) {\n            return undefined; \u002F\u002F ours, but nothing wrong on our side\n        }\n        return l10n.t('...');\n    }\n}\n```\n\n`undefined` is always the safe answer: it means \"show the original error\".\n\nIf the text names an infrastructure identifier that is not in the connection string (for example a\nKubernetes service or namespace), return `{ message, identifiers }` instead of a plain string and list\neach one with its kind. Connection diagnostics' \"Hide identifiers\" can only replace names it was told\nabout.\n\nA provider may answer without inspecting the error at all. Cancellations are therefore filtered\ncentrally: `explain()` returns `undefined` for a `UserCancelledError` before any provider is asked,\nso a wizard the user escaped is never reported as an infrastructure failure.\n\n### Answer the cheap question first\n\n`explain()` runs on every foreground failure across the whole extension, so the common case must\ncost almost nothing. Order the checks so the fastest rejection happens first.\n\n- `QuickStartErrorExplainer` scans an in-memory list of managed instances before touching Docker.\n- `AtlasErrorExplainer` tests the error message shape before looking up any credentials.\n- `KubernetesErrorExplainer` checks its in-memory map before importing the tunnel machinery.\n\n### Do not cache verdicts\n\n`explain()` runs once per user-initiated failure, so caching buys nothing and costs correctness: a\nmemoized \"not running\" would still be reported right after the user starts the container and\nretries. Probe fresh every time.\n\nIf a provider ever does become expensive enough to matter, share in-flight work rather than\ncaching results, so a repeat attempt still sees the current state.\n\n### Knowing whether a cluster is yours\n\n`clusterId` is the only identity that reaches every call site. Stored connection properties do not\ntravel past the tree item, so a webview, the shell and the playground cannot read them. Pick\nwhichever of these fits your source:\n\n| Approach                                 | Example                                               | When                                           |\n| ---------------------------------------- | ----------------------------------------------------- | ---------------------------------------------- |\n| Look it up in state you already keep     | Quick Start reads `listStatuses()`                    | Your source has a live registry                |\n| Inspect the connection string            | Atlas checks the `mongodb.net` host suffix            | The endpoint identifies the source             |\n| Record it while preparing the connection | Kubernetes remembers `clusterId` in `ensureReachable` | Only the stored properties identify the source |\n\nThe third case is why `ConnectionReachabilityProvider.ensureReachable` takes an optional\n`clusterId`: that call is the one moment where both halves are known.\n\n## Never touch the error\n\n`explain()` returns text. It does not modify, replace, or attach properties to the error, and\nneither should you. A lot of code here inspects errors by identity rather than by text:\n\n- `instanceof UserCancelledError` decides failure versus cancellation, in roughly 25 places;\n- `instanceof QueryError`, `MongoBulkWriteError` and `SettingsHintError` change how a failure is handled;\n- `error.code` is read for server codes (115, 235) and socket codes (`ECONNRESET`, `ENOTFOUND`);\n- `errorCodeExtractor.ts` reads `error.cause.cause.code` at a **fixed depth**, so an extra wrapper level breaks Collection view error-code detection;\n- `extractErrorCode()` parses a `[CODE-12345]` prefix from the **start** of a message, so prepending text breaks the shell and the playground;\n- the tRPC boundary rebuilds errors as `{ code, name, message, stack, cause }`, so a custom property never reaches a webview anyway.\n\nLeave the error alone and none of this can break.\n\n## Adding a call site\n\nCall `explain()` where you are about to **render** a failure, then show its message instead of the\nraw one and keep the raw text as detail. Rethrow the original error unchanged so telemetry and\nevery downstream check keep working.\n\n```ts\nconst explanation = await ErrorExplanationService.explain({ clusterId, error });\nvoid vscode.window.showErrorMessage(explanation?.message ?? l10n.t('Failed to load ...'), {\n    modal: true,\n    detail: error instanceof Error ? error.message : String(error),\n});\n```\n\nExisting call sites:\n\n| Surface                                           | File                                                                                  |\n| ------------------------------------------------- | ------------------------------------------------------------------------------------- |\n| Every tree view, below a cluster                  | [BaseExtendedTreeDataProvider.ts](..\u002F..\u002F..\u002Fsrc\u002Ftree\u002FBaseExtendedTreeDataProvider.ts)  |\n| Cluster connect and list databases                | [ClusterItemBase.ts](..\u002F..\u002F..\u002Fsrc\u002Ftree\u002Fdocumentdb\u002FClusterItemBase.ts)                 |\n| Shell connect banner                              | [DocumentDBShellPty.ts](..\u002F..\u002F..\u002Fsrc\u002Fdocumentdb\u002Fshell\u002FDocumentDBShellPty.ts)          |\n| Query playground                                  | [executePlaygroundCode.ts](..\u002F..\u002F..\u002Fsrc\u002Fcommands\u002Fplayground\u002FexecutePlaygroundCode.ts) |\n| Tree-node commands (create, drop, …)              | [commandErrorHandling.ts](..\u002F..\u002F..\u002Fsrc\u002Futils\u002FcommandErrorHandling.ts)                 |\n| Any webview, via `common.explainOperationFailure` | [appRouter.ts](..\u002F..\u002F..\u002Fsrc\u002Fwebviews\u002F_integration\u002FappRouter.ts)                       |\n\nTree views need no per-view wiring: `wrapGetChildrenWithErrorAndStateHandling` translates on the way\nout, so any provider built on the base class is covered. Commands registered with\n`registerCommandWithTreeNodeUnwrappingAndModalErrors` are covered the same way, via the tree node\nthey receive.\n\n### Do not call it from background paths\n\nBackground work shows nothing, so translating there costs I\u002FO for no benefit. Leave these alone:\ncollection and document count badges, index count badges, the Collection view document count, and\nthe Query Insights stage 1 prefetch. They already swallow their errors on purpose.\n\n### Webviews\n\nAn explanation cannot ride along on an error across the tRPC boundary, so a webview asks for one:\n\n```tsx\n.catch(async (error) => {\n    const cause = error instanceof Error ? error.message : String(error);\n    const explained = await trpcClient.common.explainOperationFailure.query({ message: cause });\n    void trpcClient.common.displayErrorMessage.mutate({\n        message: explained ?? l10n.t('Error while running the query'),\n        modal: true,\n        cause,\n    });\n});\n```\n\n`explainOperationFailure` reads the `clusterId` from the webview's tRPC context and returns `null`\nwhen nothing applies. Only the error MESSAGE crosses the boundary, so a provider that needs an\nerror's class or `code` cannot be served this way. Never wrap an error to smuggle text through.\n\n## Writing the message\n\n- Do not assert what happened. Say \"we cannot find\", \"very likely\", \"does not appear to be\".\n- \"We\" is fine and is the established voice.\n- Say what the user can do next, and where.\n- Keep it to one paragraph. The message becomes the heading of a modal, where a bulleted block\n  renders as several lines of bold text; the raw driver error already occupies the detail area.\n  `AtlasErrorExplainer` returns `summarizeAtlasTlsHandshakeRejection()` for this reason, while\n  the Discovery-view modal keeps the longer `describeAtlasTlsHandshakeRejection()` as its detail.\n- No em dashes or en dashes.\n- Wrap every string in `l10n.t()` and run `npm run l10n`.\n\n```ts\n\u002F\u002F Good\nl10n.t('We cannot find the DocumentDB Local container. It was very likely removed outside VS Code. You can recreate it from the Connections view, which reuses the existing data volume.')\n\n\u002F\u002F Bad: asserts a cause, and offers no next step\nl10n.t('The container was removed outside VS Code.')\n```\n\n## Related\n\n- [errorExplanationService.ts](..\u002F..\u002F..\u002Fsrc\u002Fservices\u002FerrorExplanationService.ts)\n- [connectionReachabilityService.ts](..\u002F..\u002F..\u002Fsrc\u002Fservices\u002FconnectionReachabilityService.ts) prepares a connection _before_ connecting; this service explains a failure _afterwards_\n- [tree-cluster-architecture](..\u002Ftree-cluster-architecture\u002FSKILL.md) for `clusterId` versus `treeId`\n- [telemetry-instrumentation](..\u002Ftelemetry-instrumentation\u002FSKILL.md)\n","# Error Translation\n\nA connection can fail for reasons that have nothing to do with the database: a container was\nstopped, a port-forward tunnel died, a service closed the TLS handshake. The driver reports these\nas `ECONNREFUSED`, a server-selection timeout, or an OpenSSL alert, none of which tell the user\nwhat to do.\n\n`ErrorExplanationService` lets the source that owns the infrastructure explain the failure in\nits own words.\n\n## The one rule\n\n> **Providers translate. They never show UI and never recover.**\n\nNo dialogs, no notifications, no progress bars, no starting or restarting anything, no retries, no\nprompts. A provider receives an error and returns text.\n\nThis is not a style preference. One user action often runs several database commands, several\nactions can fail at the same time, and many calls happen on background paths that show nothing. A\nprovider that showed UI or repaired state would produce duplicate dialogs, dialogs nobody asked\nfor, and errors that are already obsolete by the time they appear.\n\nAnything with a side effect belongs at the call site, which alone knows whether the user is\nwatching, whether the operation was a read or a write, and which surface is right.\n\n## Adding a provider\n\nImplement `ErrorExplanationProvider` and register it in\n[ClustersExtension.registerDiscoveryServices](..\u002F..\u002F..\u002Fsrc\u002Fdocumentdb\u002FClustersExtension.ts),\nnext to the existing ones.\n\n```ts\nexport class MyErrorExplainer implements ErrorExplanationProvider {\n    public readonly id = 'my-source';\n\n    public async explain({ clusterId, error }: ErrorExplanationRequest): Promise\u003Cstring | undefined> {\n        if (!isMine(clusterId)) {\n            return undefined; \u002F\u002F not ours: the caller shows the original error\n        }\n        if (!looksLikeMyFailure(error)) {\n            return undefined; \u002F\u002F ours, but nothing wrong on our side\n        }\n        return l10n.t('...');\n    }\n}\n```\n\n`undefined` is always the safe answer: it means \"show the original error\".\n\nIf the text names an infrastructure identifier that is not in the connection string (for example a\nKubernetes service or namespace), return `{ message, identifiers }` instead of a plain string and list\neach one with its kind. Connection diagnostics' \"Hide identifiers\" can only replace names it was told\nabout.\n\nA provider may answer without inspecting the error at all. Cancellations are therefore filtered\ncentrally: `explain()` returns `undefined` for a `UserCancelledError` before any provider is asked,\nso a wizard the user escaped is never reported as an infrastructure failure.\n\n### Answer the cheap question first\n\n`explain()` runs on every foreground failure across the whole extension, so the common case must\ncost almost nothing. Order the checks so the fastest rejection happens first.\n\n- `QuickStartErrorExplainer` scans an in-memory list of managed instances before touching Docker.\n- `AtlasErrorExplainer` tests the error message shape before looking up any credentials.\n- `KubernetesErrorExplainer` checks its in-memory map before importing the tunnel machinery.\n\n### Do not cache verdicts\n\n`explain()` runs once per user-initiated failure, so caching buys nothing and costs correctness: a\nmemoized \"not running\" would still be reported right after the user starts the container and\nretries. Probe fresh every time.\n\nIf a provider ever does become expensive enough to matter, share in-flight work rather than\ncaching results, so a repeat attempt still sees the current state.\n\n### Knowing whether a cluster is yours\n\n`clusterId` is the only identity that reaches every call site. Stored connection properties do not\ntravel past the tree item, so a webview, the shell and the playground cannot read them. Pick\nwhichever of these fits your source:\n\n| Approach                                 | Example                                               | When                                           |\n| ---------------------------------------- | ----------------------------------------------------- | ---------------------------------------------- |\n| Look it up in state you already keep     | Quick Start reads `listStatuses()`                    | Your source has a live registry                |\n| Inspect the connection string            | Atlas checks the `mongodb.net` host suffix            | The endpoint identifies the source             |\n| Record it while preparing the connection | Kubernetes remembers `clusterId` in `ensureReachable` | Only the stored properties identify the source |\n\nThe third case is why `ConnectionReachabilityProvider.ensureReachable` takes an optional\n`clusterId`: that call is the one moment where both halves are known.\n\n## Never touch the error\n\n`explain()` returns text. It does not modify, replace, or attach properties to the error, and\nneither should you. A lot of code here inspects errors by identity rather than by text:\n\n- `instanceof UserCancelledError` decides failure versus cancellation, in roughly 25 places;\n- `instanceof QueryError`, `MongoBulkWriteError` and `SettingsHintError` change how a failure is handled;\n- `error.code` is read for server codes (115, 235) and socket codes (`ECONNRESET`, `ENOTFOUND`);\n- `errorCodeExtractor.ts` reads `error.cause.cause.code` at a **fixed depth**, so an extra wrapper level breaks Collection view error-code detection;\n- `extractErrorCode()` parses a `[CODE-12345]` prefix from the **start** of a message, so prepending text breaks the shell and the playground;\n- the tRPC boundary rebuilds errors as `{ code, name, message, stack, cause }`, so a custom property never reaches a webview anyway.\n\nLeave the error alone and none of this can break.\n\n## Adding a call site\n\nCall `explain()` where you are about to **render** a failure, then show its message instead of the\nraw one and keep the raw text as detail. Rethrow the original error unchanged so telemetry and\nevery downstream check keep working.\n\n```ts\nconst explanation = await ErrorExplanationService.explain({ clusterId, error });\nvoid vscode.window.showErrorMessage(explanation?.message ?? l10n.t('Failed to load ...'), {\n    modal: true,\n    detail: error instanceof Error ? error.message : String(error),\n});\n```\n\nExisting call sites:\n\n| Surface                                           | File                                                                                  |\n| ------------------------------------------------- | ------------------------------------------------------------------------------------- |\n| Every tree view, below a cluster                  | [BaseExtendedTreeDataProvider.ts](..\u002F..\u002F..\u002Fsrc\u002Ftree\u002FBaseExtendedTreeDataProvider.ts)  |\n| Cluster connect and list databases                | [ClusterItemBase.ts](..\u002F..\u002F..\u002Fsrc\u002Ftree\u002Fdocumentdb\u002FClusterItemBase.ts)                 |\n| Shell connect banner                              | [DocumentDBShellPty.ts](..\u002F..\u002F..\u002Fsrc\u002Fdocumentdb\u002Fshell\u002FDocumentDBShellPty.ts)          |\n| Query playground                                  | [executePlaygroundCode.ts](..\u002F..\u002F..\u002Fsrc\u002Fcommands\u002Fplayground\u002FexecutePlaygroundCode.ts) |\n| Tree-node commands (create, drop, …)              | [commandErrorHandling.ts](..\u002F..\u002F..\u002Fsrc\u002Futils\u002FcommandErrorHandling.ts)                 |\n| Any webview, via `common.explainOperationFailure` | [appRouter.ts](..\u002F..\u002F..\u002Fsrc\u002Fwebviews\u002F_integration\u002FappRouter.ts)                       |\n\nTree views need no per-view wiring: `wrapGetChildrenWithErrorAndStateHandling` translates on the way\nout, so any provider built on the base class is covered. Commands registered with\n`registerCommandWithTreeNodeUnwrappingAndModalErrors` are covered the same way, via the tree node\nthey receive.\n\n### Do not call it from background paths\n\nBackground work shows nothing, so translating there costs I\u002FO for no benefit. Leave these alone:\ncollection and document count badges, index count badges, the Collection view document count, and\nthe Query Insights stage 1 prefetch. They already swallow their errors on purpose.\n\n### Webviews\n\nAn explanation cannot ride along on an error across the tRPC boundary, so a webview asks for one:\n\n```tsx\n.catch(async (error) => {\n    const cause = error instanceof Error ? error.message : String(error);\n    const explained = await trpcClient.common.explainOperationFailure.query({ message: cause });\n    void trpcClient.common.displayErrorMessage.mutate({\n        message: explained ?? l10n.t('Error while running the query'),\n        modal: true,\n        cause,\n    });\n});\n```\n\n`explainOperationFailure` reads the `clusterId` from the webview's tRPC context and returns `null`\nwhen nothing applies. Only the error MESSAGE crosses the boundary, so a provider that needs an\nerror's class or `code` cannot be served this way. Never wrap an error to smuggle text through.\n\n## Writing the message\n\n- Do not assert what happened. Say \"we cannot find\", \"very likely\", \"does not appear to be\".\n- \"We\" is fine and is the established voice.\n- Say what the user can do next, and where.\n- Keep it to one paragraph. The message becomes the heading of a modal, where a bulleted block\n  renders as several lines of bold text; the raw driver error already occupies the detail area.\n  `AtlasErrorExplainer` returns `summarizeAtlasTlsHandshakeRejection()` for this reason, while\n  the Discovery-view modal keeps the longer `describeAtlasTlsHandshakeRejection()` as its detail.\n- No em dashes or en dashes.\n- Wrap every string in `l10n.t()` and run `npm run l10n`.\n\n```ts\n\u002F\u002F Good\nl10n.t('We cannot find the DocumentDB Local container. It was very likely removed outside VS Code. You can recreate it from the Connections view, which reuses the existing data volume.')\n\n\u002F\u002F Bad: asserts a cause, and offers no next step\nl10n.t('The container was removed outside VS Code.')\n```\n\n## Related\n\n- [errorExplanationService.ts](..\u002F..\u002F..\u002Fsrc\u002Fservices\u002FerrorExplanationService.ts)\n- [connectionReachabilityService.ts](..\u002F..\u002F..\u002Fsrc\u002Fservices\u002FconnectionReachabilityService.ts) prepares a connection _before_ connecting; this service explains a failure _afterwards_\n- [tree-cluster-architecture](..\u002Ftree-cluster-architecture\u002FSKILL.md) for `clusterId` versus `treeId`\n- [telemetry-instrumentation](..\u002Ftelemetry-instrumentation\u002FSKILL.md)\n",{"name":5,"description":7},"main","a2ea119b85b92857e68374e35a300362ab5f44c3",".github\u002Fskills\u002Ferror-translation",23,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode-documentdb","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-11-11 06:07:34",{"source":8,"skillName":5,"commands":61,"prompt":71,"zipAvailable":72},[62,65,68],{"tool":63,"command":64},"npx","npx skills add microsoft\u002Fvscode-documentdb --skill error-translation",{"tool":66,"command":67},"bunx","bunx skills add microsoft\u002Fvscode-documentdb --skill error-translation",{"tool":69,"command":70},"pnpm","pnpm dlx skills add microsoft\u002Fvscode-documentdb --skill error-translation","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode-documentdb\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ferror-translation\u002FSKILL.md",true,[],[75,111,134,165,191,209],{"skillNo":76,"name":77,"nameZh":6,"description":78,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":79,"categories":80,"keywords":89,"publishedAt":46},"01M69BSZH60F9JW3N87ZBSKTW8","writing-release-notes","Generates release notes and changelog entries for the DocumentDB extension for Visual Studio Code, and announces releases on GitHub Discussions. Use when preparing version releases, creating patch update notes, writing changelog entries, documenting new features and fixes, or posting a release or patch release announcement to Discussions. Handles both major\u002Fminor versions (new file) and patch updates (append to existing file).","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode-documentdb\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fwriting-release-notes\u002FSKILL.md",[81,84],{"categoryNo":82,"categoryName":83,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":85,"categoryName":86,"taxonomyType":87,"taxonomyTypeDesc":88},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[90,91,92,93,94,95,96,97,98,99,33,30,100,101,102,103,104,105,106,107,108,109,110],"notes","release","release notes","writing","writing release notes","github","update","visual studio code","visual studio","code","updates","studio","patch","changelog","announcement","release announcement","releases","features","append","posting","fixes",{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":117,"publishedAt":46},"01M69BSXPVQWSQVYNT6QK38VN1","webview-trpc-messaging","Implements tRPC-based communication between VS Code extension host and React webviews. Use when creating new webview procedures (queries, mutations, subscriptions), adding a new webview router, wiring up a webview controller, using the tRPC client from React components, applying telemetry middleware (telemetryMiddlewareBody), or supporting AbortSignal-based cancellation in webview operations.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode-documentdb\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fwebview-trpc-messaging\u002FSKILL.md",[],[118,119,120,121,99,122,123,124,125,126,33,127,32,30,128,129,130,131,132,133],"webview trpc messaging","messaging","trpc","telemetry","components","react","react components","middleware","up","host","wiring","router","queries","controller","mutations","communication",{"skillNo":135,"name":136,"nameZh":6,"description":137,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":138,"categories":139,"keywords":146,"publishedAt":46},"01M69BSV4V52VBDF3RZ3E6Y61T","ux-pr-review","Prepare and run an agent-assisted UX \u002F workflow review of a pull request. Use when the operator says \"I'm about to work on a UX PR review, please prepare\", \"prepare a UX review for PR","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode-documentdb\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fux-pr-review\u002FSKILL.md",[140,143],{"categoryNo":141,"categoryName":142,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":144,"categoryName":145,"taxonomyType":87,"taxonomyTypeDesc":88},"01JBSEEDCAT000000000000032","设计师",[147,148,149,150,151,152,153,154,155,156,157,27,158,32,30,159,160,161,162,163,164],"ux pr review","pr","pr review","review","ux","pull request","prepare","workflow","run","pull","ux review","work on","workflow review","work","please","request","about","operator",{"skillNo":166,"name":167,"nameZh":6,"description":168,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":169,"categories":170,"keywords":171,"publishedAt":46},"01M69BSRV752CSC1NBMFWDCKB5","tree-cluster-architecture","Patterns for cluster nodes and tree data providers in vscode-documentdb. Use when adding or changing a cluster tree item, discovery provider, Connections\u002FAzure\u002FDiscovery tree hierarchy, tree\u002Flist mode, cluster identity, treeId\u002FclusterId lookup, Collection View import\u002Fexport resolution, reveal behavior, credentials, shell actions, or copy connection string support.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode-documentdb\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ftree-cluster-architecture\u002FSKILL.md",[],[172,173,40,174,45,175,176,177,178,179,30,180,181,182,183,184,185,186,187,188,189,190],"tree cluster architecture","architecture","cluster","support","vscode","identity","actions","mode","collection","hierarchy","credentials","reveal","export","data","list","patterns","Providers","STRING","import",{"skillNo":192,"name":193,"nameZh":6,"description":194,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":195,"categories":196,"keywords":197,"publishedAt":46},"01M69BSPMFSH3FAR4R5TGDB468","telemetry-instrumentation","Instrumentation patterns for telemetry in the vscode-documentdb extension. Use when adding telemetry to a feature, enriching existing telemetry with properties or measurements, linking related events with correlation IDs, instrumenting commands or tree views, suppressing noisy events, or deciding what data points to capture. Also use when asked to \"add telemetry\" or \"improve telemetry\" for any feature.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode-documentdb\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ftelemetry-instrumentation\u002FSKILL.md",[],[198,121,199,176,200,34,30,201,202,185,187,203,204,40,205,27,32,206,207,208],"telemetry instrumentation","instrumentation","ids","linking","commands","add","events","feature","Existing","with","properties",{"skillNo":210,"name":211,"nameZh":6,"description":212,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":213,"categories":214,"keywords":216,"publishedAt":46},"01M69BSMRAT64W6F3F15FVQ9QK","skill-creator","Guide for creating effective GitHub Copilot skills (.github\u002Fskills\u002F) in this repository. Use when creating a new skill, updating an existing skill, or when asked about skill structure, format, or best practices for the vscode-documentdb project.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode-documentdb\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fskill-creator\u002FSKILL.md",[215],{"categoryNo":141,"categoryName":142,"taxonomyType":21,"taxonomyTypeDesc":22},[217,218,219,95,220,176,221,27,222,33,32,206,30,223,224,225,163,226,227,228],"skill creator","creator","github copilot","best practices","copilot","project","structure","github copilot skills","copilot skills","format","repository","new skill"]