[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M69BWX0NY6SCW7H5EMVVC7R1":3,"skill-same:01M69BWX0NY6SCW7H5EMVVC7R1":71},{"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":42,"linkOnly":43,"markdownContent":44,"markdownBody":45,"frontMatter":46,"refName":47,"commitSha":48,"skillDirectory":49,"forksCount":50,"repositoryHtmlUrl":51,"repositoryHomepageUrl":52,"ownerHtmlUrl":53,"ownerBlogUrl":54,"ownerDescription":55,"updatedAt":56,"install":57,"resources":70},"01M69BWX0NY6SCW7H5EMVVC7R1","openvmm-ci-investigation",null,"Investigate CI failures on OpenVMM PRs. Load when a PR has failing CI checks, you need to download and analyze test artifacts, or you need to diagnose build, fmt, clippy, or VMM test failures.","microsoft\u002Fopenvmm","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M69BWP49YBS03WTCPVZB5TY8",1972,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fopenvmm\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fopenvmm-ci-investigation\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41],"openvmm ci investigation","ci","investigation","download","failing","when","prs","load","you","clippy","build","analyze","test","investigate","vmm","artifacts","pr","diagnose","2026-11-10 10:12:30",false,"---\nname: openvmm-ci-investigation\ndescription: Investigate CI failures on OpenVMM PRs. Load when a PR has failing CI checks, you need to download and analyze test artifacts, or you need to diagnose build, fmt, clippy, or VMM test failures.\n---\n\n# Investigating CI Failures\n\nWhen a PR has failing CI checks, prefer the investigation script. If it is\nunavailable or incompatible with the execution environment, use the read-only\nmanual fallback below.\n\nThe script reads from GitHub and downloads artifacts locally. It does not\nmodify remote resources. Downloads use the system temporary directory; check\nthat this destination is suitable for the execution environment.\n\n## Step 1: Run the Script\n\n```bash\n# Investigate a specific PR by number\npython3 repo_support\u002Finvestigate_ci.py 2946\n\n# Or by run ID directly\npython3 repo_support\u002Finvestigate_ci.py 23017249697\n```\n\nPrefer explicit PR or run identifiers for reproducible investigation. Omitting\nthe identifier requires the script to resolve the current branch's PR.\n\nThe script automatically:\n1. Resolves the PR to **every** failed CI run for its head commit. A commit\n   can have multiple workflows (e.g. \"OpenVMM PR\" and \"OpenVMM Docs PR\"),\n   and each failing one is investigated in turn — so don't assume a single\n   run covers everything. Only the newest run of each workflow is used, so\n   superseded runs are ignored; a `NOTE: \u003Cworkflow> is still in_progress`\n   line means results are incomplete and more failures may appear later.\n2. Identifies failed jobs\n3. Downloads `*-unit-tests-junit-xml` artifacts and parses JUnit XML for\n   unit test failures\n4. Downloads `*-vmm-tests-logs` artifacts if they exist\n5. Finds tests with `petri.failed` markers and extracts ERROR\u002FWARN lines\n6. If no test or JUnit artifacts exist (build\u002Ffmt\u002Fclippy failure), shows the\n   tail of the failed job's log\n\n## Step 2: Analyze the Script Output\n\nRead the script's output to identify:\n- Which tests failed (unit tests and\u002For VMM tests)\n- Error messages and root causes\n- Whether it's a build\u002Ffmt\u002Fclippy failure vs. a test failure\n\nWhen more than one run failed, the output is split by `# RUN n of m` banners.\nCheck **all** of them — a docs failure and a build failure are reported in\nseparate runs.\n\nThen use the information to diagnose the issue and suggest fixes.\n\n## Step 3: Diagnose from Logs and Code\n\n**Always try to diagnose the failure from CI logs, test code, and error\nmessages first.** Most failures can be understood without local reproduction.\nRead the relevant test source, trace the error through the code, and form\na hypothesis before considering local repro.\n\n## Step 4: Reproduce Locally (Only If Needed)\n\nIf you cannot diagnose the failure from logs alone, **ask the user** whether\nthey want to attempt local reproduction before proceeding. Do not\nautomatically start building or running tests on the user's machine.\n\nIf the user agrees, check whether the failing platform matches the host\narchitecture — you can only reproduce tests locally on the same arch. If\nit doesn't match, explain this to the user and continue diagnosing from\nCI logs and test code.\n\nFor approved local reproduction, select the workflow for the failure:\n\n| Failure | Workflow |\n|---------|----------|\n| Unit test | `cargo nextest run --profile agent -p \u003Cpackage>` with a focused filter |\n| VMM test | Load the `vmm-tests` skill and use `cargo xflowey vmm-tests-run` |\n| Rustdoc | `cargo doc --no-deps -p \u003Cpackage>` |\n| Guide | The Guide build workflow in `flowey\u002Fflowey_lib_hvlite\u002Fsrc\u002Fbuild_guide.rs`, including plugin setup, `mdbook test`, and `mdbook build` |\n| Build, clippy, or formatting | The failed job's command, scoped to the affected package or rule where possible |\n\nDo **not** use `cargo nextest run -p vmm_tests` directly; it won't have the\nrequired artifacts.\n\n## Reference: Manual Commands\n\n> Use these if the script is unavailable, fails, is incompatible with the\n> execution environment, or you need to inspect a specific artifact.\n\nFollow these steps:\n\n### 1. Find the failing run\n\n```bash\n# Get the run ID for a PR\ngh pr checks \u003CPR_NUMBER> -R microsoft\u002Fopenvmm\n# Or list runs for a specific commit\ngh run list -R microsoft\u002Fopenvmm --commit \u003CSHA>\n```\n\n### 2. Identify the failing job\n\n```bash\ngh run view \u003CRUN_ID> -R microsoft\u002Fopenvmm --json jobs \\\n  -q '[.jobs[] | select(.conclusion == \"failure\") | {name, databaseId}]'\n```\n\n### 3. Download test artifacts\n\n**Unit test results** are stored in JUnit XML artifacts named\n`{platform}-unit-tests-junit-xml`. Known platforms include:\n- `x64-linux`\n- `aarch64-linux`\n- `aarch64-linux-musl`\n\n```bash\n# Download unit test JUnit XML for a platform\ngh run download \u003CRUN_ID> -R microsoft\u002Fopenvmm \\\n  -n aarch64-linux-unit-tests-junit-xml -D \u002Ftmp\u002Fjunit-xml\n# Parse failures from the XML\npython3 -c \"\nimport xml.etree.ElementTree as ET, sys\nfor f in __import__('pathlib').Path(sys.argv[1]).rglob('*.xml'):\n    for tc in ET.parse(f).iter('testcase'):\n        fail = tc.find('failure')\n        if fail is None:\n            fail = tc.find('error')\n        if fail is not None:\n            print(f'FAIL: {tc.get(\\\"classname\\\",\\\"\\\")}::{tc.get(\\\"name\\\",\\\"\\\")}')\n            print(f'  {fail.get(\\\"message\\\",\\\"\\\")[:200]}')\n\" \u002Ftmp\u002Fjunit-xml\n```\n\n**VMM test results** are stored in artifacts named `{platform}-vmm-tests-logs`.\nThe known platforms are:\n- `x64-windows-intel`\n- `x64-windows-intel-tdx`\n- `x64-windows-amd`\n- `x64-windows-amd-snp`\n- `x64-linux`\n- `aarch64-windows`\n\n```bash\n# Download a specific platform's test logs\ngh run download \u003CRUN_ID> -R microsoft\u002Fopenvmm \\\n  -n x64-windows-amd-snp-vmm-tests-logs -D \u002Ftmp\u002Ftest-logs\n```\n\n### 4. Find failed tests\n\nEach test gets its own directory inside the artifact. Look for `petri.failed`\nmarker files (passing tests have `petri.passed` instead):\n\n```bash\nfind \u002Ftmp\u002Ftest-logs -name \"petri.failed\"\n```\n\nThe `petri.failed` file contains the error petri recorded for the test. The\ntest's real name is in `petri.test`, which petri writes before the test body\nruns — so a directory with `petri.test` but *no* result marker is a test that\nwas killed or crashed before it could report.\n\n### 5. Extract errors from petri.jsonl\n\nThe `petri.jsonl` file in each test directory is the primary structured log.\nEach line is a JSON object with fields: `timestamp`, `source`, `severity`,\n`message`. Filter for `ERROR` and `WARN` severity for a quick diagnosis:\n\n```bash\npython3 -c \"\nimport json, sys\nfor line in open(sys.argv[1]):\n    try:\n        e = json.loads(line.strip())\n        if e.get('severity') in ('ERROR', 'WARN'):\n            print(f'[{e[\\\"severity\\\"]}] {e.get(\\\"source\\\",\\\"?\\\")}: {e.get(\\\"message\\\",\\\"\\\").strip()[:200]}')\n    except: pass\n\" \u002Ftmp\u002Ftest-logs\u002F\u003Ctest-dir>\u002Fpetri.jsonl\n```\n\n## Artifact Contents\n\n### Unit test JUnit XML\n\nArtifacts named `{platform}-unit-tests-junit-xml` contain JUnit XML files\nwith `\u003Ctestcase>` elements. Failed tests have `\u003Cfailure>` or `\u003Cerror>`\nchildren with `message` attributes describing the failure. These are the\nprimary artifacts for diagnosing unit test \u002F cargo-nextest failures.\n\n### VMM test logs (petri)\n\nEach test directory contains:\n- `petri.jsonl` — Structured JSON Lines log **(primary file for investigation)**\n- `petri.log` — Plain text version of the test log\n- `petri.test` — The test's name, written before the test body runs\n- `petri.passed` or `petri.failed` — Pass\u002Ffail marker; a failure marker holds the error\n- `openhcl.log` — OpenHCL serial console output, if the test exercised OpenHCL\n- `hyperv.log` — Hyper-V event log, if the test exercises the Hyper-V backend\n- `openvmm.log` — OpenVMM serial console output, if the test exercises the OpenVMM backend\n- `guest.log`, `uefi.log` — Guest OS serial output\n- Sometimes: `screenshot_*.png` — periodic screenshots of the guest\n- Sometimes: `dumpfile.dmp`\n\n## Viewing Results in Browser\n\nTest results are uploaded to Azure Blob Storage and viewable at:\n`https:\u002F\u002Fopenvmm.dev\u002Ftest-results\u002F#\u002Fruns\u002F\u003CRUN_ID>_\u003CRUN_ATTEMPT>`\n\nLogs are uploaded per re-run attempt, so the run key includes the attempt\nnumber (`1` for the first attempt). `investigate_ci.py` prints the correct\nURL in its summary.\n\n## Common Failure Patterns\n\n- **Unit test failure**: A `unit tests` job failed. The script downloads\n  JUnit XML artifacts and shows the failing test names and messages. Common\n  causes: new test code that relies on OS capabilities not available in CI\n  (e.g. TAP devices, elevated permissions).\n- **Formatting \u002F house-rules**: The `quick check [fmt, clippy x64-linux]` job\n  failed. No test artifacts will exist. Check the job log for the specific rule\n  that failed. For approved reproduction, run `cargo xtask fmt --fix` locally.\n- **Guide failure**: The `build mdbook guide` job in \"OpenVMM Docs PR\" failed.\n  Check for broken Guide markdown, links, or code examples and\n  `[ERROR] (mdbook::...)` diagnostics. Use the Guide workflow above for approved\n  reproduction, not `cargo doc`. No test artifacts will exist.\n- **Rustdoc failure**: The `build and check docs` job in \"OpenVMM Docs PR\" failed.\n  Rustdoc warnings are denied in CI. Use package-scoped `cargo doc` for approved\n  reproduction. No test artifacts will exist.\n- **TripleFault**: VM hit a fatal error during boot. Check `petri.jsonl` for\n  Hyper-V Worker\u002FChipset errors. Often infrastructure-related, not caused by\n  the PR's code changes.\n- **Timeout**: Test exceeded its time limit. Check if the VM booted at all.\n- **Guest assertion failure**: Guest-side test failed. Check `guest.log`.\n- **Build failure**: No test artifacts will exist. Check the job log directly\n  with `gh run view \u003CRUN_ID> --job \u003CJOB_ID> --log`.\n\n## Important API Note\n\nThe `gh run view --json artifacts` flag does **not** exist. To list artifacts\nfor a run, use the GitHub API directly:\n\n```bash\ngh api repos\u002Fmicrosoft\u002Fopenvmm\u002Factions\u002Fruns\u002F\u003CRUN_ID>\u002Fartifacts\n```\n","# Investigating CI Failures\n\nWhen a PR has failing CI checks, prefer the investigation script. If it is\nunavailable or incompatible with the execution environment, use the read-only\nmanual fallback below.\n\nThe script reads from GitHub and downloads artifacts locally. It does not\nmodify remote resources. Downloads use the system temporary directory; check\nthat this destination is suitable for the execution environment.\n\n## Step 1: Run the Script\n\n```bash\n# Investigate a specific PR by number\npython3 repo_support\u002Finvestigate_ci.py 2946\n\n# Or by run ID directly\npython3 repo_support\u002Finvestigate_ci.py 23017249697\n```\n\nPrefer explicit PR or run identifiers for reproducible investigation. Omitting\nthe identifier requires the script to resolve the current branch's PR.\n\nThe script automatically:\n1. Resolves the PR to **every** failed CI run for its head commit. A commit\n   can have multiple workflows (e.g. \"OpenVMM PR\" and \"OpenVMM Docs PR\"),\n   and each failing one is investigated in turn — so don't assume a single\n   run covers everything. Only the newest run of each workflow is used, so\n   superseded runs are ignored; a `NOTE: \u003Cworkflow> is still in_progress`\n   line means results are incomplete and more failures may appear later.\n2. Identifies failed jobs\n3. Downloads `*-unit-tests-junit-xml` artifacts and parses JUnit XML for\n   unit test failures\n4. Downloads `*-vmm-tests-logs` artifacts if they exist\n5. Finds tests with `petri.failed` markers and extracts ERROR\u002FWARN lines\n6. If no test or JUnit artifacts exist (build\u002Ffmt\u002Fclippy failure), shows the\n   tail of the failed job's log\n\n## Step 2: Analyze the Script Output\n\nRead the script's output to identify:\n- Which tests failed (unit tests and\u002For VMM tests)\n- Error messages and root causes\n- Whether it's a build\u002Ffmt\u002Fclippy failure vs. a test failure\n\nWhen more than one run failed, the output is split by `# RUN n of m` banners.\nCheck **all** of them — a docs failure and a build failure are reported in\nseparate runs.\n\nThen use the information to diagnose the issue and suggest fixes.\n\n## Step 3: Diagnose from Logs and Code\n\n**Always try to diagnose the failure from CI logs, test code, and error\nmessages first.** Most failures can be understood without local reproduction.\nRead the relevant test source, trace the error through the code, and form\na hypothesis before considering local repro.\n\n## Step 4: Reproduce Locally (Only If Needed)\n\nIf you cannot diagnose the failure from logs alone, **ask the user** whether\nthey want to attempt local reproduction before proceeding. Do not\nautomatically start building or running tests on the user's machine.\n\nIf the user agrees, check whether the failing platform matches the host\narchitecture — you can only reproduce tests locally on the same arch. If\nit doesn't match, explain this to the user and continue diagnosing from\nCI logs and test code.\n\nFor approved local reproduction, select the workflow for the failure:\n\n| Failure | Workflow |\n|---------|----------|\n| Unit test | `cargo nextest run --profile agent -p \u003Cpackage>` with a focused filter |\n| VMM test | Load the `vmm-tests` skill and use `cargo xflowey vmm-tests-run` |\n| Rustdoc | `cargo doc --no-deps -p \u003Cpackage>` |\n| Guide | The Guide build workflow in `flowey\u002Fflowey_lib_hvlite\u002Fsrc\u002Fbuild_guide.rs`, including plugin setup, `mdbook test`, and `mdbook build` |\n| Build, clippy, or formatting | The failed job's command, scoped to the affected package or rule where possible |\n\nDo **not** use `cargo nextest run -p vmm_tests` directly; it won't have the\nrequired artifacts.\n\n## Reference: Manual Commands\n\n> Use these if the script is unavailable, fails, is incompatible with the\n> execution environment, or you need to inspect a specific artifact.\n\nFollow these steps:\n\n### 1. Find the failing run\n\n```bash\n# Get the run ID for a PR\ngh pr checks \u003CPR_NUMBER> -R microsoft\u002Fopenvmm\n# Or list runs for a specific commit\ngh run list -R microsoft\u002Fopenvmm --commit \u003CSHA>\n```\n\n### 2. Identify the failing job\n\n```bash\ngh run view \u003CRUN_ID> -R microsoft\u002Fopenvmm --json jobs \\\n  -q '[.jobs[] | select(.conclusion == \"failure\") | {name, databaseId}]'\n```\n\n### 3. Download test artifacts\n\n**Unit test results** are stored in JUnit XML artifacts named\n`{platform}-unit-tests-junit-xml`. Known platforms include:\n- `x64-linux`\n- `aarch64-linux`\n- `aarch64-linux-musl`\n\n```bash\n# Download unit test JUnit XML for a platform\ngh run download \u003CRUN_ID> -R microsoft\u002Fopenvmm \\\n  -n aarch64-linux-unit-tests-junit-xml -D \u002Ftmp\u002Fjunit-xml\n# Parse failures from the XML\npython3 -c \"\nimport xml.etree.ElementTree as ET, sys\nfor f in __import__('pathlib').Path(sys.argv[1]).rglob('*.xml'):\n    for tc in ET.parse(f).iter('testcase'):\n        fail = tc.find('failure')\n        if fail is None:\n            fail = tc.find('error')\n        if fail is not None:\n            print(f'FAIL: {tc.get(\\\"classname\\\",\\\"\\\")}::{tc.get(\\\"name\\\",\\\"\\\")}')\n            print(f'  {fail.get(\\\"message\\\",\\\"\\\")[:200]}')\n\" \u002Ftmp\u002Fjunit-xml\n```\n\n**VMM test results** are stored in artifacts named `{platform}-vmm-tests-logs`.\nThe known platforms are:\n- `x64-windows-intel`\n- `x64-windows-intel-tdx`\n- `x64-windows-amd`\n- `x64-windows-amd-snp`\n- `x64-linux`\n- `aarch64-windows`\n\n```bash\n# Download a specific platform's test logs\ngh run download \u003CRUN_ID> -R microsoft\u002Fopenvmm \\\n  -n x64-windows-amd-snp-vmm-tests-logs -D \u002Ftmp\u002Ftest-logs\n```\n\n### 4. Find failed tests\n\nEach test gets its own directory inside the artifact. Look for `petri.failed`\nmarker files (passing tests have `petri.passed` instead):\n\n```bash\nfind \u002Ftmp\u002Ftest-logs -name \"petri.failed\"\n```\n\nThe `petri.failed` file contains the error petri recorded for the test. The\ntest's real name is in `petri.test`, which petri writes before the test body\nruns — so a directory with `petri.test` but *no* result marker is a test that\nwas killed or crashed before it could report.\n\n### 5. Extract errors from petri.jsonl\n\nThe `petri.jsonl` file in each test directory is the primary structured log.\nEach line is a JSON object with fields: `timestamp`, `source`, `severity`,\n`message`. Filter for `ERROR` and `WARN` severity for a quick diagnosis:\n\n```bash\npython3 -c \"\nimport json, sys\nfor line in open(sys.argv[1]):\n    try:\n        e = json.loads(line.strip())\n        if e.get('severity') in ('ERROR', 'WARN'):\n            print(f'[{e[\\\"severity\\\"]}] {e.get(\\\"source\\\",\\\"?\\\")}: {e.get(\\\"message\\\",\\\"\\\").strip()[:200]}')\n    except: pass\n\" \u002Ftmp\u002Ftest-logs\u002F\u003Ctest-dir>\u002Fpetri.jsonl\n```\n\n## Artifact Contents\n\n### Unit test JUnit XML\n\nArtifacts named `{platform}-unit-tests-junit-xml` contain JUnit XML files\nwith `\u003Ctestcase>` elements. Failed tests have `\u003Cfailure>` or `\u003Cerror>`\nchildren with `message` attributes describing the failure. These are the\nprimary artifacts for diagnosing unit test \u002F cargo-nextest failures.\n\n### VMM test logs (petri)\n\nEach test directory contains:\n- `petri.jsonl` — Structured JSON Lines log **(primary file for investigation)**\n- `petri.log` — Plain text version of the test log\n- `petri.test` — The test's name, written before the test body runs\n- `petri.passed` or `petri.failed` — Pass\u002Ffail marker; a failure marker holds the error\n- `openhcl.log` — OpenHCL serial console output, if the test exercised OpenHCL\n- `hyperv.log` — Hyper-V event log, if the test exercises the Hyper-V backend\n- `openvmm.log` — OpenVMM serial console output, if the test exercises the OpenVMM backend\n- `guest.log`, `uefi.log` — Guest OS serial output\n- Sometimes: `screenshot_*.png` — periodic screenshots of the guest\n- Sometimes: `dumpfile.dmp`\n\n## Viewing Results in Browser\n\nTest results are uploaded to Azure Blob Storage and viewable at:\n`https:\u002F\u002Fopenvmm.dev\u002Ftest-results\u002F#\u002Fruns\u002F\u003CRUN_ID>_\u003CRUN_ATTEMPT>`\n\nLogs are uploaded per re-run attempt, so the run key includes the attempt\nnumber (`1` for the first attempt). `investigate_ci.py` prints the correct\nURL in its summary.\n\n## Common Failure Patterns\n\n- **Unit test failure**: A `unit tests` job failed. The script downloads\n  JUnit XML artifacts and shows the failing test names and messages. Common\n  causes: new test code that relies on OS capabilities not available in CI\n  (e.g. TAP devices, elevated permissions).\n- **Formatting \u002F house-rules**: The `quick check [fmt, clippy x64-linux]` job\n  failed. No test artifacts will exist. Check the job log for the specific rule\n  that failed. For approved reproduction, run `cargo xtask fmt --fix` locally.\n- **Guide failure**: The `build mdbook guide` job in \"OpenVMM Docs PR\" failed.\n  Check for broken Guide markdown, links, or code examples and\n  `[ERROR] (mdbook::...)` diagnostics. Use the Guide workflow above for approved\n  reproduction, not `cargo doc`. No test artifacts will exist.\n- **Rustdoc failure**: The `build and check docs` job in \"OpenVMM Docs PR\" failed.\n  Rustdoc warnings are denied in CI. Use package-scoped `cargo doc` for approved\n  reproduction. No test artifacts will exist.\n- **TripleFault**: VM hit a fatal error during boot. Check `petri.jsonl` for\n  Hyper-V Worker\u002FChipset errors. Often infrastructure-related, not caused by\n  the PR's code changes.\n- **Timeout**: Test exceeded its time limit. Check if the VM booted at all.\n- **Guest assertion failure**: Guest-side test failed. Check `guest.log`.\n- **Build failure**: No test artifacts will exist. Check the job log directly\n  with `gh run view \u003CRUN_ID> --job \u003CJOB_ID> --log`.\n\n## Important API Note\n\nThe `gh run view --json artifacts` flag does **not** exist. To list artifacts\nfor a run, use the GitHub API directly:\n\n```bash\ngh api repos\u002Fmicrosoft\u002Fopenvmm\u002Factions\u002Fruns\u002F\u003CRUN_ID>\u002Fartifacts\n```\n",{"name":5,"description":7},"main","ebcd3302222379403963385f25538e35afcd3222",".github\u002Fskills\u002Fopenvmm-ci-investigation",277,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fopenvmm","http:\u002F\u002Fopenvmm.dev\u002F","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-11-15 02:18:15",{"source":8,"skillName":5,"commands":58,"prompt":68,"zipAvailable":69},[59,62,65],{"tool":60,"command":61},"npx","npx skills add microsoft\u002Fopenvmm --skill openvmm-ci-investigation",{"tool":63,"command":64},"bunx","bunx skills add microsoft\u002Fopenvmm --skill openvmm-ci-investigation",{"tool":66,"command":67},"pnpm","pnpm dlx skills add microsoft\u002Fopenvmm --skill openvmm-ci-investigation","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fopenvmm\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fopenvmm-ci-investigation\u002FSKILL.md",true,[],[72,91,111,131],{"skillNo":73,"name":74,"nameZh":6,"description":75,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":78,"publishedAt":42},"01M69BX123NC683P7MH2Y7B08K","vmm-tests","Run VMM tests locally with cargo xflowey vmm-tests-run. Load when running or debugging VMM tests, or when you need to understand the petri test framework, artifact handling, or cross-compilation for VMM tests.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fopenvmm\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fvmm-tests\u002FSKILL.md",[],[79,80,38,36,81,82,83,84,85,86,87,88,32,31,89,29,90],"tests","vmm tests","test framework","debugging","run","framework","artifact","cargo","understand","with","for","running",{"skillNo":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":97,"publishedAt":42},"01M69BWYZCDJJASP457EK9EPWB","update-mu-msvm","Update OpenVMM UEFI firmware to the latest published microsoft\u002Fmu_msvm release. Use when updating mu_msvm, bumping the UEFI dependency, refreshing firmware Nix hashes, or preparing the firmware ingestion pull request.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fopenvmm\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fupdate-mu-msvm\u002FSKILL.md",[],[98,99,100,101,102,103,104,29,105,106,107,108,9,109,110],"update","update mu msvm","firmware","latest","ingestion","dependency","use","UEFI","pull","release","pull request","request","nix",{"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":42},"01M69BWVDKTXGYTGQ5AGFBB8AQ","guide-maintenance","Maintain the OpenVMM Guide. Load when: (1) adding, removing, or moving Guide pages, (2) adding new device crates or adding or changing CLI interfaces that need doc coverage, or (3) auditing Guide freshness against code changes.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fopenvmm\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fguide-maintenance\u002FSKILL.md",[],[118,119,120,29,121,122,123,124,125,126,127,128,31,129,130],"guide maintenance","guide","maintenance","cli","code","doc","coverage","doc coverage","device","maintain","pages","changes","new",{"skillNo":132,"name":133,"nameZh":6,"description":134,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":135,"categories":136,"keywords":142,"publishedAt":42},"01M69BWS8XZJH7G018FXMXR1QV","fuzzing","Run, optimize, and debug OpenVMM fuzzers. Covers cargo-fuzz targets, crash reproduction, lldb debugging, code coverage analysis, entropy optimization, and multi-target parallel campaigns.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fopenvmm\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ffuzzing\u002FSKILL.md",[137],{"categoryNo":138,"categoryName":139,"taxonomyType":140,"taxonomyTypeDesc":141},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[133,143,144,145,82,83,122,146,147,148,149,124,150,151,152,153,86,154,155,156],"multi","coverage analysis","debug","Optimization","entropy","analysis","parallel","crash","optimize","campaigns","code coverage","targets","lldb","target"]