[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M69ARPMK4GHCD723YBTWYYJS":3,"skill-same:01M69ARPMK4GHCD723YBTWYYJS":87},{"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":26,"publishedAt":47,"linkOnly":48,"markdownContent":49,"markdownBody":50,"frontMatter":51,"refName":54,"commitSha":55,"skillDirectory":56,"forksCount":57,"repositoryHtmlUrl":58,"repositoryHomepageUrl":6,"ownerHtmlUrl":59,"ownerBlogUrl":60,"ownerDescription":61,"updatedAt":62,"install":63,"resources":76},"01M69ARPMK4GHCD723YBTWYYJS","e2e-tests",null,"Autonomously launch, monitor, retry, and report all Physical AI cloud E2E tests across independent Azure ML and OSMO GPU infrastructure.","microsoft\u002Fphysical-ai-toolchain","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M69ARCAV4WR03MSZSQPHZ2S8",138,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fphysical-ai-toolchain\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fe2e-tests\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署",[27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46],"tests","e2e tests","e2e","kubectl","retry","with","physical","across","azure cli","jq","Bash","cli","cloud","gpu","report","monitor","ml","azure","launch","linux","2026-11-10 10:12:30",false,"---\nname: testing\ndescription: Test patterns, fixture structure, and when to use E2E vs unit tests.\n---\n\n# Testing\n\nUse this skill when writing or modifying tests in this repository.\n\n## Rust crate tests\n\nUnit tests live alongside code in `#[cfg(test)]` modules. Integration tests go in each crate's `tests\u002F` directory.\n\n```bash\ncargo test -p microsoft-webui-handler   # one crate\ncargo test --workspace                   # all crates\ncargo xtask test                         # via xtask (part of quality gate)\n```\n\nEvery code change ships with tests:\n\n| Change type | Requirement |\n|-------------|-------------|\n| New public API | At least one unit test per function\u002Fmethod |\n| Bug fix | Regression test that fails without the fix |\n| Performance change | Benchmark comparison (before\u002Fafter) |\n| Refactor | Existing tests pass unchanged |\n\nNever remove, weaken, or `#[ignore]` an existing test unless explicitly asked.\n\n## WebUI Node package tests\n\n`cargo xtask test` builds the host native addon and the WebUI TypeScript package,\nthen runs `pnpm --filter @microsoft\u002Fwebui test` with `WEBUI_ADDON_PATH` set to the\nartifact reported by Cargo. This includes the projection compiler, adapter,\nclass-factory, parser, and native build\u002Frender regressions in both the local\n`cargo xtask check` gate and the PR Test job. Browser suites run separately via\n`cargo xtask e2e`.\n\n## Shared test utilities (`webui-test-utils`)\n\nThe `webui-test-utils` crate provides common Rust test helpers, builders, and fixtures. Check it before writing new helpers - avoid duplicating across crates.\n\n```toml\n[dev-dependencies]\nwebui-test-utils = { path = \"..\u002Fwebui-test-utils\" }\n```\n\n## Docs component tests\n\nColocate docs component tests under `docs\u002F.webui-press\u002Fcomponents\u002F\u003Ccomponent>\u002F`,\nfor example `benchmark-preview\u002Fbenchmark-preview.test.ts`. Keep component\ncoverage with its owner rather than in `packages\u002Fwebui-press\u002Ftests\u002F`.\n\nKeep tutorial tests beside the Markdown lessons in `docs\u002Fstart\u002F` and\nsite-navigation tests beside their regions in `docs\u002F.webui-press\u002Fregions\u002F`.\nThe shared Press runner includes these tests through\n`pnpm --filter @microsoft\u002Fwebui-press test`. Its `build:test` command type-checks\nand bundles these locations into `dist-test`; use unique owner-prefixed test\nfilenames. Reuse the existing native and website fixture helpers. Test modules\nare not component runtime entries and must not enter the published site.\n\n## webui-framework E2E fixtures\n\nThe `packages\u002Fwebui-framework` package uses Playwright for E2E tests. Each fixture is a mini WebUI app compiled and rendered by the real pipeline.\n\nSee `tests\u002Ffixtures\u002FREADME.md` for the full reference.\n\n### Fixture structure\n\n```\ntests\u002Ffixtures\u002F\u003Cname>\u002F\n  src\u002F\n    index.html                 Page template (uses the component)\n    \u003Ctag-name>\u002F\n      \u003Ctag-name>.html          Component template (real WebUI syntax)\n      \u003Ctag-name>.css           Component CSS (optional)\n  state.json                   Initial render state (all bound properties)\n  element.ts                   Component class (NO template registration)\n  \u003Cname>.spec.ts               Playwright tests\n  webui.config.json            Build options override (optional)\n```\n\n### How it works\n\nThe test server (`fixture-render.ts`) auto-discovers fixtures with `src\u002Findex.html`, calls `@microsoft\u002Fwebui` `build()` + `render()` to produce SSR HTML with template IIFEs, hydration markers, and inventory. The result is served at `\u002F\u003Cname>\u002Ffixture.html`.\n\n### Creating a new fixture\n\n1. Create `fixtures\u002F\u003Cname>\u002Fsrc\u002Findex.html` — page template:\n\n```html\n\u003C!DOCTYPE html>\n\u003Chtml lang=\"en\">\n\u003Chead>\u003Cmeta charset=\"utf-8\">\u003Ctitle>My Fixture\u003C\u002Ftitle>\u003C\u002Fhead>\n\u003Cbody>\n  \u003Ctest-widget label=\"Hello\">\u003C\u002Ftest-widget>\n\u003C\u002Fbody>\n\u003C\u002Fhtml>\n```\n\n2. Create `fixtures\u002F\u003Cname>\u002Fsrc\u002Ftest-widget\u002Ftest-widget.html` — component template:\n\n```html\n\u003Cspan class=\"label\">{{label}}\u003C\u002Fspan>\n\u003Cspan class=\"count\">{{count}}\u003C\u002Fspan>\n\u003Cbutton class=\"inc\" @click=\"{increment()}\">+\u003C\u002Fbutton>\n```\n\n3. Create `fixtures\u002F\u003Cname>\u002Fstate.json` — initial state:\n\n```json\n{ \"label\": \"Hello\", \"count\": 0 }\n```\n\n4. Create `fixtures\u002F\u003Cname>\u002Felement.ts` — component class only:\n\n```typescript\n\u002F\u002F Copyright (c) Microsoft Corporation.\n\u002F\u002F Licensed under the MIT license.\n\nimport { WebUIElement, attr, observable } from '..\u002F..\u002F..\u002Fsrc\u002Findex.js';\n\nexport class TestWidget extends WebUIElement {\n  @attr label = 'Hello';\n  @observable count = 0;\n\n  increment(): void {\n    this.count += 1;\n  }\n}\n\nTestWidget.define('test-widget');\n```\n\n5. Create `fixtures\u002F\u003Cname>\u002F\u003Cname>.spec.ts` — Playwright tests:\n\n```typescript\n\u002F\u002F Copyright (c) Microsoft Corporation.\n\u002F\u002F Licensed under the MIT license.\n\nimport { expect, test } from '@playwright\u002Ftest';\n\ntest.describe('widget fixture', () => {\n  test.beforeEach(async ({ page }) => {\n    await page.goto('\u002F\u003Cname>\u002Ffixture.html');\n    await page.waitForFunction(() => {\n      const el = document.querySelector('test-widget');\n      return el && (el as any).$ready === true;\n    });\n  });\n\n  test('renders SSR content', async ({ page }) => {\n    await expect(page.locator('test-widget .label')).toHaveText('Hello');\n    await expect(page.locator('test-widget .count')).toHaveText('0');\n  });\n\n  test('updates on click', async ({ page }) => {\n    await page.locator('test-widget .inc').click();\n    await expect(page.locator('test-widget .count')).toHaveText('1');\n  });\n});\n```\n\n### Template syntax quick reference\n\n| Feature | Syntax |\n|---------|--------|\n| Text binding | `{{propertyName}}` |\n| Event binding | `@click=\"{handler()}\"` or `@click=\"{handler(e)}\"` |\n| Boolean attribute | `?disabled=\"{{isDisabled}}\"` |\n| Dynamic attribute | `href=\"{{url}}\"` |\n| Mixed attribute | `href=\"\u002Fitems\u002F{{id}}\"` |\n| Complex property | `:items=\"{{items}}\"` |\n| Element ref | `w-ref=\"{myElement}\"` |\n| Conditional | `\u003Cif condition=\"show\">...\u003C\u002Fif>` |\n| Negation | `\u003Cif condition=\"!hidden\">...\u003C\u002Fif>` |\n| Comparison | `\u003Cif condition=\"count > 0\">...\u003C\u002Fif>` |\n| Compound | `\u003Cif condition=\"active && !busy\">...\u003C\u002Fif>` |\n| Loop | `\u003Cfor each=\"item in items\">...\u003C\u002Ffor>` |\n| Nested loop | `\u003Cfor each=\"group in groups\">...\u003Cfor each=\"item in group.items\">...\u003C\u002Ffor>\u003C\u002Ffor>` |\n| Shadow DOM | `\u003Ctemplate shadowrootmode=\"open\">...\u003C\u002Ftemplate>` |\n| Root event | `\u003Ctemplate shadowrootmode=\"open\" @click=\"{handler(e)}\">` |\n| Slot | `\u003Cslot>\u003C\u002Fslot>` |\n\n### Dynamic children pattern\n\nComponents only created via `document.createElement()` (not in any template) need a false `\u003Cif>` in the page template to make their template IIFEs available:\n\n```html\n\u003Cbody>\n  \u003Cmy-host>\u003C\u002Fmy-host>\n  \u003Cif condition=\"showChild\">\u003Cmy-child>\u003C\u002Fmy-child>\u003C\u002Fif>\n\u003C\u002Fbody>\n```\n\nWith `state.json`: `{ \"showChild\": false }`.\n\n### Per-fixture build config\n\nCreate `webui.config.json` to override build options:\n\n```json\n{ \"css\": \"module\" }\n```\n\n### Light and Shadow fixtures\n\nOrdinary unwrapped fixture components exercise the Shadow default. Set\n`\"dom\": \"light\"` in `webui.config.json` to exercise global Light rendering; a\nfixture component requiring Shadow inside that build must author a sole\ntop-level `\u003Ctemplate shadowrootmode=\"open\">`. A sole bare top-level\n`\u003Ctemplate>` explicitly exercises Light even in the default Shadow fixture.\nSee `fixtures\u002Fdom-default\u002F` and\n`fixtures\u002Flight-dom\u002F` for both paths through the real pipeline. Reserve manual\n`registerCompiledTemplate` fixtures for raw template-metadata scenarios.\n\n### Running framework E2E tests\n\n```bash\ncd packages\u002Fwebui-framework\npnpm build                    # build the framework\npnpm test                     # unit + E2E tests\nnpx playwright test           # E2E only\nnpx playwright test tests\u002Ffixtures\u002F\u003Cname>\u002F  # one fixture\n```\n\n### Test support package (`@microsoft\u002Fwebui-test-support`)\n\nThe `packages\u002Fwebui-test-support` package provides:\n\n- **`registerCompiledTemplate(name, meta)`** — register a raw `TemplateMeta` object (for manual\u002Flight-DOM fixtures)\n- **`renderTemplateScript(name, meta)`** — render a template as an inline `\u003Cscript>` tag\n- **`renderFixtures({ fixturesRoot })`** — build+render all pipeline fixtures\n- **`buildFixtureEntries({ ... })`** — bundle element.ts files via esbuild\n- **`startFixtureServer({ ... })`** — start the HTTP fixture server\n\n## When to use what\n\n| Scenario | Tool |\n|----------|------|\n| Rust crate logic (parsing, rendering, state, expressions) | `#[test]` unit tests |\n| Rust crate integration (full pipeline) | `tests\u002F` integration tests |\n| Rust performance | `cargo bench` with Criterion |\n| Framework hydration, reactive updates, DOM behavior | Playwright E2E fixtures |\n| Router navigation, lazy loading, chain diffing | Playwright E2E fixtures |\n| Template metadata encoding\u002Fdecoding | Node unit tests (`pnpm test:unit`) |\n","# Testing\n\nUse this skill when writing or modifying tests in this repository.\n\n## Rust crate tests\n\nUnit tests live alongside code in `#[cfg(test)]` modules. Integration tests go in each crate's `tests\u002F` directory.\n\n```bash\ncargo test -p microsoft-webui-handler   # one crate\ncargo test --workspace                   # all crates\ncargo xtask test                         # via xtask (part of quality gate)\n```\n\nEvery code change ships with tests:\n\n| Change type | Requirement |\n|-------------|-------------|\n| New public API | At least one unit test per function\u002Fmethod |\n| Bug fix | Regression test that fails without the fix |\n| Performance change | Benchmark comparison (before\u002Fafter) |\n| Refactor | Existing tests pass unchanged |\n\nNever remove, weaken, or `#[ignore]` an existing test unless explicitly asked.\n\n## WebUI Node package tests\n\n`cargo xtask test` builds the host native addon and the WebUI TypeScript package,\nthen runs `pnpm --filter @microsoft\u002Fwebui test` with `WEBUI_ADDON_PATH` set to the\nartifact reported by Cargo. This includes the projection compiler, adapter,\nclass-factory, parser, and native build\u002Frender regressions in both the local\n`cargo xtask check` gate and the PR Test job. Browser suites run separately via\n`cargo xtask e2e`.\n\n## Shared test utilities (`webui-test-utils`)\n\nThe `webui-test-utils` crate provides common Rust test helpers, builders, and fixtures. Check it before writing new helpers - avoid duplicating across crates.\n\n```toml\n[dev-dependencies]\nwebui-test-utils = { path = \"..\u002Fwebui-test-utils\" }\n```\n\n## Docs component tests\n\nColocate docs component tests under `docs\u002F.webui-press\u002Fcomponents\u002F\u003Ccomponent>\u002F`,\nfor example `benchmark-preview\u002Fbenchmark-preview.test.ts`. Keep component\ncoverage with its owner rather than in `packages\u002Fwebui-press\u002Ftests\u002F`.\n\nKeep tutorial tests beside the Markdown lessons in `docs\u002Fstart\u002F` and\nsite-navigation tests beside their regions in `docs\u002F.webui-press\u002Fregions\u002F`.\nThe shared Press runner includes these tests through\n`pnpm --filter @microsoft\u002Fwebui-press test`. Its `build:test` command type-checks\nand bundles these locations into `dist-test`; use unique owner-prefixed test\nfilenames. Reuse the existing native and website fixture helpers. Test modules\nare not component runtime entries and must not enter the published site.\n\n## webui-framework E2E fixtures\n\nThe `packages\u002Fwebui-framework` package uses Playwright for E2E tests. Each fixture is a mini WebUI app compiled and rendered by the real pipeline.\n\nSee `tests\u002Ffixtures\u002FREADME.md` for the full reference.\n\n### Fixture structure\n\n```\ntests\u002Ffixtures\u002F\u003Cname>\u002F\n  src\u002F\n    index.html                 Page template (uses the component)\n    \u003Ctag-name>\u002F\n      \u003Ctag-name>.html          Component template (real WebUI syntax)\n      \u003Ctag-name>.css           Component CSS (optional)\n  state.json                   Initial render state (all bound properties)\n  element.ts                   Component class (NO template registration)\n  \u003Cname>.spec.ts               Playwright tests\n  webui.config.json            Build options override (optional)\n```\n\n### How it works\n\nThe test server (`fixture-render.ts`) auto-discovers fixtures with `src\u002Findex.html`, calls `@microsoft\u002Fwebui` `build()` + `render()` to produce SSR HTML with template IIFEs, hydration markers, and inventory. The result is served at `\u002F\u003Cname>\u002Ffixture.html`.\n\n### Creating a new fixture\n\n1. Create `fixtures\u002F\u003Cname>\u002Fsrc\u002Findex.html` — page template:\n\n```html\n\u003C!DOCTYPE html>\n\u003Chtml lang=\"en\">\n\u003Chead>\u003Cmeta charset=\"utf-8\">\u003Ctitle>My Fixture\u003C\u002Ftitle>\u003C\u002Fhead>\n\u003Cbody>\n  \u003Ctest-widget label=\"Hello\">\u003C\u002Ftest-widget>\n\u003C\u002Fbody>\n\u003C\u002Fhtml>\n```\n\n2. Create `fixtures\u002F\u003Cname>\u002Fsrc\u002Ftest-widget\u002Ftest-widget.html` — component template:\n\n```html\n\u003Cspan class=\"label\">{{label}}\u003C\u002Fspan>\n\u003Cspan class=\"count\">{{count}}\u003C\u002Fspan>\n\u003Cbutton class=\"inc\" @click=\"{increment()}\">+\u003C\u002Fbutton>\n```\n\n3. Create `fixtures\u002F\u003Cname>\u002Fstate.json` — initial state:\n\n```json\n{ \"label\": \"Hello\", \"count\": 0 }\n```\n\n4. Create `fixtures\u002F\u003Cname>\u002Felement.ts` — component class only:\n\n```typescript\n\u002F\u002F Copyright (c) Microsoft Corporation.\n\u002F\u002F Licensed under the MIT license.\n\nimport { WebUIElement, attr, observable } from '..\u002F..\u002F..\u002Fsrc\u002Findex.js';\n\nexport class TestWidget extends WebUIElement {\n  @attr label = 'Hello';\n  @observable count = 0;\n\n  increment(): void {\n    this.count += 1;\n  }\n}\n\nTestWidget.define('test-widget');\n```\n\n5. Create `fixtures\u002F\u003Cname>\u002F\u003Cname>.spec.ts` — Playwright tests:\n\n```typescript\n\u002F\u002F Copyright (c) Microsoft Corporation.\n\u002F\u002F Licensed under the MIT license.\n\nimport { expect, test } from '@playwright\u002Ftest';\n\ntest.describe('widget fixture', () => {\n  test.beforeEach(async ({ page }) => {\n    await page.goto('\u002F\u003Cname>\u002Ffixture.html');\n    await page.waitForFunction(() => {\n      const el = document.querySelector('test-widget');\n      return el && (el as any).$ready === true;\n    });\n  });\n\n  test('renders SSR content', async ({ page }) => {\n    await expect(page.locator('test-widget .label')).toHaveText('Hello');\n    await expect(page.locator('test-widget .count')).toHaveText('0');\n  });\n\n  test('updates on click', async ({ page }) => {\n    await page.locator('test-widget .inc').click();\n    await expect(page.locator('test-widget .count')).toHaveText('1');\n  });\n});\n```\n\n### Template syntax quick reference\n\n| Feature | Syntax |\n|---------|--------|\n| Text binding | `{{propertyName}}` |\n| Event binding | `@click=\"{handler()}\"` or `@click=\"{handler(e)}\"` |\n| Boolean attribute | `?disabled=\"{{isDisabled}}\"` |\n| Dynamic attribute | `href=\"{{url}}\"` |\n| Mixed attribute | `href=\"\u002Fitems\u002F{{id}}\"` |\n| Complex property | `:items=\"{{items}}\"` |\n| Element ref | `w-ref=\"{myElement}\"` |\n| Conditional | `\u003Cif condition=\"show\">...\u003C\u002Fif>` |\n| Negation | `\u003Cif condition=\"!hidden\">...\u003C\u002Fif>` |\n| Comparison | `\u003Cif condition=\"count > 0\">...\u003C\u002Fif>` |\n| Compound | `\u003Cif condition=\"active && !busy\">...\u003C\u002Fif>` |\n| Loop | `\u003Cfor each=\"item in items\">...\u003C\u002Ffor>` |\n| Nested loop | `\u003Cfor each=\"group in groups\">...\u003Cfor each=\"item in group.items\">...\u003C\u002Ffor>\u003C\u002Ffor>` |\n| Shadow DOM | `\u003Ctemplate shadowrootmode=\"open\">...\u003C\u002Ftemplate>` |\n| Root event | `\u003Ctemplate shadowrootmode=\"open\" @click=\"{handler(e)}\">` |\n| Slot | `\u003Cslot>\u003C\u002Fslot>` |\n\n### Dynamic children pattern\n\nComponents only created via `document.createElement()` (not in any template) need a false `\u003Cif>` in the page template to make their template IIFEs available:\n\n```html\n\u003Cbody>\n  \u003Cmy-host>\u003C\u002Fmy-host>\n  \u003Cif condition=\"showChild\">\u003Cmy-child>\u003C\u002Fmy-child>\u003C\u002Fif>\n\u003C\u002Fbody>\n```\n\nWith `state.json`: `{ \"showChild\": false }`.\n\n### Per-fixture build config\n\nCreate `webui.config.json` to override build options:\n\n```json\n{ \"css\": \"module\" }\n```\n\n### Light and Shadow fixtures\n\nOrdinary unwrapped fixture components exercise the Shadow default. Set\n`\"dom\": \"light\"` in `webui.config.json` to exercise global Light rendering; a\nfixture component requiring Shadow inside that build must author a sole\ntop-level `\u003Ctemplate shadowrootmode=\"open\">`. A sole bare top-level\n`\u003Ctemplate>` explicitly exercises Light even in the default Shadow fixture.\nSee `fixtures\u002Fdom-default\u002F` and\n`fixtures\u002Flight-dom\u002F` for both paths through the real pipeline. Reserve manual\n`registerCompiledTemplate` fixtures for raw template-metadata scenarios.\n\n### Running framework E2E tests\n\n```bash\ncd packages\u002Fwebui-framework\npnpm build                    # build the framework\npnpm test                     # unit + E2E tests\nnpx playwright test           # E2E only\nnpx playwright test tests\u002Ffixtures\u002F\u003Cname>\u002F  # one fixture\n```\n\n### Test support package (`@microsoft\u002Fwebui-test-support`)\n\nThe `packages\u002Fwebui-test-support` package provides:\n\n- **`registerCompiledTemplate(name, meta)`** — register a raw `TemplateMeta` object (for manual\u002Flight-DOM fixtures)\n- **`renderTemplateScript(name, meta)`** — render a template as an inline `\u003Cscript>` tag\n- **`renderFixtures({ fixturesRoot })`** — build+render all pipeline fixtures\n- **`buildFixtureEntries({ ... })`** — bundle element.ts files via esbuild\n- **`startFixtureServer({ ... })`** — start the HTTP fixture server\n\n## When to use what\n\n| Scenario | Tool |\n|----------|------|\n| Rust crate logic (parsing, rendering, state, expressions) | `#[test]` unit tests |\n| Rust crate integration (full pipeline) | `tests\u002F` integration tests |\n| Rust performance | `cargo bench` with Criterion |\n| Framework hydration, reactive updates, DOM behavior | Playwright E2E fixtures |\n| Router navigation, lazy loading, chain diffing | Playwright E2E fixtures |\n| Template metadata encoding\u002Fdecoding | Node unit tests (`pnpm test:unit`) |\n",{"name":52,"description":53},"testing","Test patterns, fixture structure, and when to use E2E vs unit tests.","main","fd2d75282e29638442f161e202bf109d38e3ceb3",".github\u002Fskills\u002Fe2e-tests",72,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fphysical-ai-toolchain","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-11-11 03:38:51",{"source":8,"skillName":52,"commands":64,"prompt":74,"zipAvailable":75},[65,68,71],{"tool":66,"command":67},"npx","npx skills add microsoft\u002Fphysical-ai-toolchain --skill testing",{"tool":69,"command":70},"bunx","bunx skills add microsoft\u002Fphysical-ai-toolchain --skill testing",{"tool":72,"command":73},"pnpm","pnpm dlx skills add microsoft\u002Fphysical-ai-toolchain --skill testing","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fphysical-ai-toolchain\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fe2e-tests\u002FSKILL.md",true,[77,83],{"path":78,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":81,"sourceHtmlUrl":82},"scripts\u002Flib\u002Fhandle-state.sh","SCRIPT","脚本",11993,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fphysical-ai-toolchain\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fe2e-tests\u002Fscripts\u002Flib\u002Fhandle-state.sh",{"path":84,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":85,"sourceHtmlUrl":86},"scripts\u002Frun-e2e-tests.sh",31763,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fphysical-ai-toolchain\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fe2e-tests\u002Fscripts\u002Frun-e2e-tests.sh",[88,113,133,151,176,199],{"skillNo":89,"name":90,"nameZh":6,"description":91,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":99,"publishedAt":47},"01M69AS2WAAD5CZ9S9CBSEZ226","synthetic-data","Generate synthetic training data using NVIDIA Cosmos world foundation models for SDG pipelines","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fphysical-ai-toolchain\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fsynthetic-data\u002FSKILL.md",[94],{"categoryNo":95,"categoryName":96,"taxonomyType":97,"taxonomyTypeDesc":98},"01JBSEEDCAT000000000000033","数据分析师","PROFESSION","适用职业",[100,101,102,103,104,105,106,107,108,109,110,111,112],"synthetic data","data","synthetic","training","generate","NVIDIA","pipelines","models","foundation","world","cosmos","for","Training Data",{"skillNo":114,"name":115,"nameZh":6,"description":116,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":117,"categories":118,"keywords":119,"publishedAt":47},"01M69AS0T2FF3R3YHFQZAF4X3F","osmo-lerobot-training","Submit, monitor, analyze, and evaluate LeRobot imitation learning training jobs on OSMO with Azure ML MLflow integration and inference evaluation - Brought to you by microsoft\u002Fphysical-ai-toolchain","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fphysical-ai-toolchain\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fosmo-lerobot-training\u002FSKILL.md",[],[120,103,121,9,44,43,42,122,123,124,125,126,127,33,128,129,32,130,131,132],"osmo lerobot training","inference","integration","Evaluation","learning","analyze","jobs","mlflow","submit","toolchain","you","evaluate","Training Jobs",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":140,"publishedAt":47},"01M69ARYW92CVD1H0AZ10RDWFF","infrastructure","Deploy and manage Azure infrastructure for the Physical AI Toolchain including Terraform IaC, Kubernetes setup, GPU configuration, and network topology","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fphysical-ai-toolchain\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Finfrastructure\u002FSKILL.md",[139],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[135,141,142,143,44,144,40,145,146,147,148,149,33,150,129,111],"kubernetes","deploy","setup","terraform","topology","network","iac","manage","configuration","terraform iac",{"skillNo":152,"name":153,"nameZh":6,"description":154,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":155,"categories":156,"keywords":157,"publishedAt":47},"01M69ARWVH4BA8RWYR6EVJV2XF","fleet-intelligence","Monitor robot fleet telemetry via Azure IoT Operations, drift detection, Grafana dashboards, and Fabric analytics","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fphysical-ai-toolchain\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ffleet-intelligence\u002FSKILL.md",[],[158,159,160,161,162,44,42,163,164,165,166,167,168,169,170,171,172,173,174,175],"fleet intelligence","intelligence","fleet","telemetry","analytics","fabric","iot","grafana","detection","grafana dashboards","dashboards","operations","drift","robot","via","azure iot operations","azure iot","drift detection",{"skillNo":177,"name":178,"nameZh":6,"description":179,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":180,"categories":181,"keywords":189,"publishedAt":47},"01M69ARV021DNVZY7DWWDMBM7H","fleet-deployment","Deploy trained robot policies to edge fleets via FluxCD GitOps, image automation, and deployment gating","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fphysical-ai-toolchain\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ffleet-deployment\u002FSKILL.md",[182,183,186],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":184,"categoryName":185,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":187,"categoryName":188,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[190,191,160,192,193,142,194,195,171,172,196,197,198],"fleet deployment","deployment","image","automation","edge","gitops","fluxcd","fleets","gating",{"skillNo":200,"name":201,"nameZh":6,"description":202,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":203,"categories":204,"keywords":207,"publishedAt":47},"01M69ARRY00ZAZDB0N7EERY8Q8","environment-deployment","Generate, transfer, and consume environment-specific Azure, AKS, OSMO, ACR, and Azure ML deployment bundles. Use when: discovering deployed environment details; creating OSMO image manifests or platform values; preparing a HiL host; uploading or downloading deployment files through Azure Key Vault; or deploying with generated environment configuration.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fphysical-ai-toolchain\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fenvironment-deployment\u002FSKILL.md",[205,206],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":184,"categoryName":185,"taxonomyType":21,"taxonomyTypeDesc":22},[208,191,209,192,44,43,104,210,211,212,213,214,149,215,216,217,32,218,219,220],"environment deployment","environment","aks","vault","generated","use","files","azure key vault","platform","host","values","manifests","when"]