[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M69BWYZCDJJASP457EK9EPWB":3,"skill-same:01M69BWYZCDJJASP457EK9EPWB":62},{"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":18,"publishedAt":33,"linkOnly":34,"markdownContent":35,"markdownBody":36,"frontMatter":37,"refName":38,"commitSha":39,"skillDirectory":40,"forksCount":41,"repositoryHtmlUrl":42,"repositoryHomepageUrl":43,"ownerHtmlUrl":44,"ownerBlogUrl":45,"ownerDescription":46,"updatedAt":47,"install":48,"resources":61},"01M69BWYZCDJJASP457EK9EPWB","update-mu-msvm",null,"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.","microsoft\u002Fopenvmm","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M69BWP49YBS03WTCPVZB5TY8",1968,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fopenvmm\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fupdate-mu-msvm\u002FSKILL.md",[],[19,20,21,9,22,23,24,25,26,27,28,29,30,31,32],"update","update mu msvm","nix","pull request","release","pull","UEFI","firmware","use","dependency","ingestion","latest","request","when","2026-11-10 10:12:30",false,"---\nname: update-mu-msvm\ndescription: >\n  Update OpenVMM UEFI firmware to the latest published microsoft\u002Fmu_msvm\n  release. Use when updating mu_msvm, bumping the UEFI dependency, refreshing\n  firmware Nix hashes, or preparing the firmware ingestion pull request.\n---\n\n# Update mu_msvm\n\nUpdate the firmware dependency, verify both architectures, and prepare a draft\npull request against `microsoft\u002Fopenvmm:main`. Follow the repository's current\ninstructions and honor any limits the user places on committing or publishing.\n\n## Execution policy\n\n- Execute routine steps end to end without asking for approval between steps.\n  A branch-name override or \"do not create a PR\" is an instruction, not a\n  reason to reconfirm the workflow.\n- Ask only for a real safety conflict or a decision that cannot be inferred:\n  conflicting user changes, an existing remote branch, divergent local\n  history, or a blocker requiring a change outside this update.\n- Complete restore, hash calculation, edits, and nonprivileged checks before\n  final Nix verification. Do not use sudo or trial builds to discover hashes.\n- Use one visible terminal task and one sudo authentication for final Nix\n  verification. The user enters their password there. Do not ask them to\n  confirm password entry or command completion in chat; collect the task's\n  result directly and retain its output so it does not need to be rerun.\n\n## 1. Prepare a clean branch\n\n1. Inspect the worktree, current branch, remotes, and local commits before\n   switching branches. Preserve existing changes. If an earlier update is\n   already in progress, establish its state before resuming.\n2. Use the user's branch-name override when supplied. Otherwise derive the\n   fork owner from `origin` and use `user\u002F\u003Cfork-owner>\u002Fuefi-update-main`.\n   Do not hard-code a maintainer's identity or local machine paths.\n3. Check the remote before creating or reusing the branch:\n\n   ```bash\n   git ls-remote --heads origin \"refs\u002Fheads\u002F$branch\"\n   ```\n\n   A failed remote query is not evidence that the branch is absent. If the\n   branch exists remotely, stop and ask how to proceed. Never automatically\n   delete it, force-push it, or overwrite an earlier update.\n4. Fetch current `main` from `https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fopenvmm.git`.\n   Check out local `main`, then create the update branch from current upstream\n   `main`. If local `main` is behind, fast-forward it only when safe. If it has\n   extra commits or has diverged, ask before proceeding; offer to create the\n   update branch directly from fetched upstream `main`, leaving local `main`\n   untouched.\n5. Inspect the branch's commits and merge-base diff against upstream `main`.\n   Do not carry unrelated local changes or commits into the firmware PR.\n   Never amend already-pushed commits or rewrite published history without\n   express permission.\n\n## 2. Discover the release and previous ingestion\n\nThe relevant files are:\n\n- [Firmware version configuration](..\u002F..\u002F..\u002Fflowey\u002Fflowey_lib_hvlite\u002Fsrc\u002F_jobs\u002Fcfg_versions.rs)\n- [Nix firmware derivation](..\u002F..\u002F..\u002Fnix\u002Fuefi_mu_msvm.nix)\n- [Flowey firmware downloader](..\u002F..\u002F..\u002Fflowey\u002Fflowey_lib_hvlite\u002Fsrc\u002Fdownload_uefi_mu_msvm.rs)\n- [Development shell](..\u002F..\u002F..\u002Fshell.nix)\n\n1. Record the previous `MU_MSVM` value from upstream `main`, before editing.\n   Use this version for the PR changelog, even if the old Nix version differs.\n2. Query the latest published, non-prerelease release from\n   [microsoft\u002Fmu_msvm](https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fmu_msvm), for example:\n\n   ```bash\n   gh api repos\u002Fmicrosoft\u002Fmu_msvm\u002Freleases\u002Flatest \\\n     --jq '{tag_name, published_at, assets: [.assets[].name]}'\n   ```\n\n   The public GitHub REST endpoint can also be queried with `curl` if `gh`\n   is unavailable. Strip the leading `v` for version strings in code.\n   Never reuse a release number from an earlier invocation without checking.\n3. Inspect the release assets and downloader before choosing URLs. Keep the\n   existing firmware flavor: legacy C core with `CLANGPDB` for X64 and AARCH64,\n   not Patina or VS2022. Do not assume historical asset names still exist.\n4. Check both `MU_MSVM` and the Nix derivation before deciding there is no\n   update. Report a no-op only when both versions match the latest release\n   and the Nix asset URLs and both unpacked hashes are verified current using\n   section 4. If Rust is current but Nix is stale, continue with the Nix\n   refresh; likewise update Rust if only it is stale. An unchanged `MU_MSVM`\n   alone is never a reason to skip a requested Nix refresh.\n\n## 3. Update and restore\n\n1. Set `MU_MSVM` to the new version.\n2. Run:\n\n   ```bash\n   cargo xflowey restore-packages\n   ```\n\n   Check that restore resolves the intended firmware version. Cache hits are\n   normal, but success alone does not establish which version was consumed.\n   The extraction cache records each archive's version under\n   `flowey-persist\u002Fflowey_lib_hvlite__download_uefi_mu_msvm\u002F.flowey_info\u002F`.\n   Confirm the marker matches `\u003Cversion>-\u003Casset-name>` before reusing a tree.\n3. Set the Nix derivation's `version` to the same version. Calculate both new\n   hashes as described below and replace them together; there is no need for\n   an intermediate edit that clears the hashes.\n4. Match the Nix URL to the actual release assets. Recent releases use\n   `firmware-RELEASE-${archToolchain}.tar.gz`; older releases used\n   `RELEASE-${archToolchain}-artifacts.tar.gz`. If Flowey also needs an asset\n   naming change, update it consistently rather than leaving restore broken.\n\n## 4. Compute and verify both Nix hashes\n\nThese are recursive hashes of the unpacked source tree used by `fetchzip`,\nnot SHA-256 hashes of the compressed downloads. Preserve `stripRoot = false`.\n\n1. Reuse the verified restored trees under\n   `flowey-persist\u002Fflowey_lib_hvlite__download_uefi_mu_msvm\u002Fextracted\u002F\u003Casset-name>\u002F`.\n   Hash the archive's extracted contents, not the parent directory or its\n   sibling `.flowey_info` metadata. Restore may only fetch the host\n   architecture. If either tree is absent or has a different version marker,\n   download that architecture's release asset without sudo and extract it to\n   a fresh temporary directory, without stripping its root.\n2. Compute both hashes locally, without accessing the Nix store:\n\n   ```bash\n   nix-hash --type sha256 --base64 \"$unpacked_tree\"\n   ```\n\n   Prefix each result with `sha256-` and fill in both architecture entries.\n   Do not use `nix-prefetch-url` when store permissions would require sudo.\n3. After the nonprivileged validation in section 5, open one visible terminal\n   task for final verification. If sudo is necessary, group all privileged\n   commands in one invocation so the user only authenticates once. Never\n   request their password in chat, capture it, or bypass authentication.\n4. In that task, first verify both UEFI derivations using the development\n   shell's pinned nixpkgs, explicitly selecting both architectures. This\n   confirms the computed hashes against real `fetchzip` behavior even if\n   another shell dependency is broken. The expression has this shape, with\n   `PINNED_NIXPKGS_URL` replaced by the current shell's pin:\n\n   ```bash\n   nix-build --no-out-link --expr '\n     let\n       pkgs = import (builtins.fetchTarball \"PINNED_NIXPKGS_URL\") {};\n     in {\n       x64 = pkgs.callPackage .\u002Fnix\u002Fuefi_mu_msvm.nix {\n         targetArch = \"x86_64\";\n       };\n       aarch64 = pkgs.callPackage .\u002Fnix\u002Fuefi_mu_msvm.nix {\n         targetArch = \"aarch64\";\n       };\n     }'\n   ```\n\n   Verify both builds succeed and install nonempty `MSVM.fd` files matching\n   their release archives. Then invoke `nix-shell` exactly once in the same\n   task. Its `--run` command should verify that `NIX_UEFI_X64` and\n   `NIX_UEFI_AARCH64` point to the expected, nonempty firmware files.\n5. If the full shell fails on an unrelated dependency, report that blocker\n   and leave unrelated hashes unchanged. Do not rerun the shell or request\n   another authentication to rediscover the same failure. Preserve the\n   independent UEFI build results and clearly distinguish their success\n   from full-shell success. A UEFI hash mismatch is a real update failure:\n   correct it and revalidate rather than committing an unverified hash.\n\n## 5. Validate before committing\n\nRun the repository's required checks for each modified package. For the usual\nversion-only Rust change, the package is `flowey_lib_hvlite`:\n\n```bash\ncargo check -p flowey_lib_hvlite\ncargo clippy --all-targets -p flowey_lib_hvlite\ncargo doc --no-deps -p flowey_lib_hvlite\ncargo nextest run --profile agent -p flowey_lib_hvlite\ncargo xtask fmt --fix\n```\n\nUse `cargo test -p flowey_lib_hvlite` only if nextest is unavailable. Do not\nfilter test output. Run formatting last; resolve failures and rerun until it\nsucceeds. Check that formatting did not introduce unrelated changes.\nThen perform the single final Nix verification task described in section 4.\n\n## 6. Commit, push, and stage the PR\n\n1. Stage only intended files. Normally these are the version configuration\n   and Nix derivation; include downloader changes only when required.\n2. Commit with the exact subject, substituting the new version:\n\n   ```text\n   deps: update mu_msvm to v\u003Cnew-version> release\n   ```\n\n   Include the repository-required co-author trailer.\n3. Push the branch to `origin`, without force.\n4. Create a **draft** PR targeting `microsoft\u002Fopenvmm:main`, using the commit\n   subject as the title. Derive the head owner from the actual origin fork.\n   The body must contain only:\n\n   ```markdown\n   Changelog: [microsoft\u002Fmu_msvm@v\u003Cprevious-version>...v\u003Cnew-version>](https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fmu_msvm\u002Fcompare\u002Fv\u003Cprevious-version>...v\u003Cnew-version>)\n   ```\n\n   Use the previous Rust ingestion recorded in step 2, not a guessed release\n   or the previous Nix version.\n5. Verify the published PR's base, head, draft status, description, commits,\n   and changed files. Confirm there are no unrelated commits or changes and\n   the local commit matches the remote branch.\n6. Remove temporary downloads and verification-only configuration that you\n   created, without deleting user files. Report the PR link, validation\n   results, and any remaining environment blockers.\n","# Update mu_msvm\n\nUpdate the firmware dependency, verify both architectures, and prepare a draft\npull request against `microsoft\u002Fopenvmm:main`. Follow the repository's current\ninstructions and honor any limits the user places on committing or publishing.\n\n## Execution policy\n\n- Execute routine steps end to end without asking for approval between steps.\n  A branch-name override or \"do not create a PR\" is an instruction, not a\n  reason to reconfirm the workflow.\n- Ask only for a real safety conflict or a decision that cannot be inferred:\n  conflicting user changes, an existing remote branch, divergent local\n  history, or a blocker requiring a change outside this update.\n- Complete restore, hash calculation, edits, and nonprivileged checks before\n  final Nix verification. Do not use sudo or trial builds to discover hashes.\n- Use one visible terminal task and one sudo authentication for final Nix\n  verification. The user enters their password there. Do not ask them to\n  confirm password entry or command completion in chat; collect the task's\n  result directly and retain its output so it does not need to be rerun.\n\n## 1. Prepare a clean branch\n\n1. Inspect the worktree, current branch, remotes, and local commits before\n   switching branches. Preserve existing changes. If an earlier update is\n   already in progress, establish its state before resuming.\n2. Use the user's branch-name override when supplied. Otherwise derive the\n   fork owner from `origin` and use `user\u002F\u003Cfork-owner>\u002Fuefi-update-main`.\n   Do not hard-code a maintainer's identity or local machine paths.\n3. Check the remote before creating or reusing the branch:\n\n   ```bash\n   git ls-remote --heads origin \"refs\u002Fheads\u002F$branch\"\n   ```\n\n   A failed remote query is not evidence that the branch is absent. If the\n   branch exists remotely, stop and ask how to proceed. Never automatically\n   delete it, force-push it, or overwrite an earlier update.\n4. Fetch current `main` from `https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fopenvmm.git`.\n   Check out local `main`, then create the update branch from current upstream\n   `main`. If local `main` is behind, fast-forward it only when safe. If it has\n   extra commits or has diverged, ask before proceeding; offer to create the\n   update branch directly from fetched upstream `main`, leaving local `main`\n   untouched.\n5. Inspect the branch's commits and merge-base diff against upstream `main`.\n   Do not carry unrelated local changes or commits into the firmware PR.\n   Never amend already-pushed commits or rewrite published history without\n   express permission.\n\n## 2. Discover the release and previous ingestion\n\nThe relevant files are:\n\n- [Firmware version configuration](..\u002F..\u002F..\u002Fflowey\u002Fflowey_lib_hvlite\u002Fsrc\u002F_jobs\u002Fcfg_versions.rs)\n- [Nix firmware derivation](..\u002F..\u002F..\u002Fnix\u002Fuefi_mu_msvm.nix)\n- [Flowey firmware downloader](..\u002F..\u002F..\u002Fflowey\u002Fflowey_lib_hvlite\u002Fsrc\u002Fdownload_uefi_mu_msvm.rs)\n- [Development shell](..\u002F..\u002F..\u002Fshell.nix)\n\n1. Record the previous `MU_MSVM` value from upstream `main`, before editing.\n   Use this version for the PR changelog, even if the old Nix version differs.\n2. Query the latest published, non-prerelease release from\n   [microsoft\u002Fmu_msvm](https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fmu_msvm), for example:\n\n   ```bash\n   gh api repos\u002Fmicrosoft\u002Fmu_msvm\u002Freleases\u002Flatest \\\n     --jq '{tag_name, published_at, assets: [.assets[].name]}'\n   ```\n\n   The public GitHub REST endpoint can also be queried with `curl` if `gh`\n   is unavailable. Strip the leading `v` for version strings in code.\n   Never reuse a release number from an earlier invocation without checking.\n3. Inspect the release assets and downloader before choosing URLs. Keep the\n   existing firmware flavor: legacy C core with `CLANGPDB` for X64 and AARCH64,\n   not Patina or VS2022. Do not assume historical asset names still exist.\n4. Check both `MU_MSVM` and the Nix derivation before deciding there is no\n   update. Report a no-op only when both versions match the latest release\n   and the Nix asset URLs and both unpacked hashes are verified current using\n   section 4. If Rust is current but Nix is stale, continue with the Nix\n   refresh; likewise update Rust if only it is stale. An unchanged `MU_MSVM`\n   alone is never a reason to skip a requested Nix refresh.\n\n## 3. Update and restore\n\n1. Set `MU_MSVM` to the new version.\n2. Run:\n\n   ```bash\n   cargo xflowey restore-packages\n   ```\n\n   Check that restore resolves the intended firmware version. Cache hits are\n   normal, but success alone does not establish which version was consumed.\n   The extraction cache records each archive's version under\n   `flowey-persist\u002Fflowey_lib_hvlite__download_uefi_mu_msvm\u002F.flowey_info\u002F`.\n   Confirm the marker matches `\u003Cversion>-\u003Casset-name>` before reusing a tree.\n3. Set the Nix derivation's `version` to the same version. Calculate both new\n   hashes as described below and replace them together; there is no need for\n   an intermediate edit that clears the hashes.\n4. Match the Nix URL to the actual release assets. Recent releases use\n   `firmware-RELEASE-${archToolchain}.tar.gz`; older releases used\n   `RELEASE-${archToolchain}-artifacts.tar.gz`. If Flowey also needs an asset\n   naming change, update it consistently rather than leaving restore broken.\n\n## 4. Compute and verify both Nix hashes\n\nThese are recursive hashes of the unpacked source tree used by `fetchzip`,\nnot SHA-256 hashes of the compressed downloads. Preserve `stripRoot = false`.\n\n1. Reuse the verified restored trees under\n   `flowey-persist\u002Fflowey_lib_hvlite__download_uefi_mu_msvm\u002Fextracted\u002F\u003Casset-name>\u002F`.\n   Hash the archive's extracted contents, not the parent directory or its\n   sibling `.flowey_info` metadata. Restore may only fetch the host\n   architecture. If either tree is absent or has a different version marker,\n   download that architecture's release asset without sudo and extract it to\n   a fresh temporary directory, without stripping its root.\n2. Compute both hashes locally, without accessing the Nix store:\n\n   ```bash\n   nix-hash --type sha256 --base64 \"$unpacked_tree\"\n   ```\n\n   Prefix each result with `sha256-` and fill in both architecture entries.\n   Do not use `nix-prefetch-url` when store permissions would require sudo.\n3. After the nonprivileged validation in section 5, open one visible terminal\n   task for final verification. If sudo is necessary, group all privileged\n   commands in one invocation so the user only authenticates once. Never\n   request their password in chat, capture it, or bypass authentication.\n4. In that task, first verify both UEFI derivations using the development\n   shell's pinned nixpkgs, explicitly selecting both architectures. This\n   confirms the computed hashes against real `fetchzip` behavior even if\n   another shell dependency is broken. The expression has this shape, with\n   `PINNED_NIXPKGS_URL` replaced by the current shell's pin:\n\n   ```bash\n   nix-build --no-out-link --expr '\n     let\n       pkgs = import (builtins.fetchTarball \"PINNED_NIXPKGS_URL\") {};\n     in {\n       x64 = pkgs.callPackage .\u002Fnix\u002Fuefi_mu_msvm.nix {\n         targetArch = \"x86_64\";\n       };\n       aarch64 = pkgs.callPackage .\u002Fnix\u002Fuefi_mu_msvm.nix {\n         targetArch = \"aarch64\";\n       };\n     }'\n   ```\n\n   Verify both builds succeed and install nonempty `MSVM.fd` files matching\n   their release archives. Then invoke `nix-shell` exactly once in the same\n   task. Its `--run` command should verify that `NIX_UEFI_X64` and\n   `NIX_UEFI_AARCH64` point to the expected, nonempty firmware files.\n5. If the full shell fails on an unrelated dependency, report that blocker\n   and leave unrelated hashes unchanged. Do not rerun the shell or request\n   another authentication to rediscover the same failure. Preserve the\n   independent UEFI build results and clearly distinguish their success\n   from full-shell success. A UEFI hash mismatch is a real update failure:\n   correct it and revalidate rather than committing an unverified hash.\n\n## 5. Validate before committing\n\nRun the repository's required checks for each modified package. For the usual\nversion-only Rust change, the package is `flowey_lib_hvlite`:\n\n```bash\ncargo check -p flowey_lib_hvlite\ncargo clippy --all-targets -p flowey_lib_hvlite\ncargo doc --no-deps -p flowey_lib_hvlite\ncargo nextest run --profile agent -p flowey_lib_hvlite\ncargo xtask fmt --fix\n```\n\nUse `cargo test -p flowey_lib_hvlite` only if nextest is unavailable. Do not\nfilter test output. Run formatting last; resolve failures and rerun until it\nsucceeds. Check that formatting did not introduce unrelated changes.\nThen perform the single final Nix verification task described in section 4.\n\n## 6. Commit, push, and stage the PR\n\n1. Stage only intended files. Normally these are the version configuration\n   and Nix derivation; include downloader changes only when required.\n2. Commit with the exact subject, substituting the new version:\n\n   ```text\n   deps: update mu_msvm to v\u003Cnew-version> release\n   ```\n\n   Include the repository-required co-author trailer.\n3. Push the branch to `origin`, without force.\n4. Create a **draft** PR targeting `microsoft\u002Fopenvmm:main`, using the commit\n   subject as the title. Derive the head owner from the actual origin fork.\n   The body must contain only:\n\n   ```markdown\n   Changelog: [microsoft\u002Fmu_msvm@v\u003Cprevious-version>...v\u003Cnew-version>](https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fmu_msvm\u002Fcompare\u002Fv\u003Cprevious-version>...v\u003Cnew-version>)\n   ```\n\n   Use the previous Rust ingestion recorded in step 2, not a guessed release\n   or the previous Nix version.\n5. Verify the published PR's base, head, draft status, description, commits,\n   and changed files. Confirm there are no unrelated commits or changes and\n   the local commit matches the remote branch.\n6. Remove temporary downloads and verification-only configuration that you\n   created, without deleting user files. Report the PR link, validation\n   results, and any remaining environment blockers.\n",{"name":5,"description":7},"main","86427897a63fcb1e5afbc3d44b733a12ad9920f4",".github\u002Fskills\u002Fupdate-mu-msvm",275,"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-14 03:05:53",{"source":8,"skillName":5,"commands":49,"prompt":59,"zipAvailable":60},[50,53,56],{"tool":51,"command":52},"npx","npx skills add microsoft\u002Fopenvmm --skill update-mu-msvm",{"tool":54,"command":55},"bunx","bunx skills add microsoft\u002Fopenvmm --skill update-mu-msvm",{"tool":57,"command":58},"pnpm","pnpm dlx skills add microsoft\u002Fopenvmm --skill update-mu-msvm","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fopenvmm\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fupdate-mu-msvm\u002FSKILL.md",true,[],[63,86,111,131],{"skillNo":64,"name":65,"nameZh":6,"description":66,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":67,"categories":68,"keywords":69,"publishedAt":33},"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",[],[70,71,72,73,74,32,75,76,77,78,79,80,81,82,83,84,85],"tests","vmm tests","vmm","artifact","running","for","load","you","with","understand","cargo","framework","run","debugging","test framework","test",{"skillNo":87,"name":88,"nameZh":6,"description":89,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":90,"categories":91,"keywords":97,"publishedAt":33},"01M69BWX0NY6SCW7H5EMVVC7R1","openvmm-ci-investigation","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.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fopenvmm\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fopenvmm-ci-investigation\u002FSKILL.md",[92],{"categoryNo":93,"categoryName":94,"taxonomyType":95,"taxonomyTypeDesc":96},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[98,99,100,101,76,77,102,103,104,105,106,72,107,108,85,32,109,110],"openvmm ci investigation","ci","investigation","analyze","clippy","build","failing","download","investigate","artifacts","prs","pr","diagnose",{"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":33},"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,121,122,123,124,125,126,127,128,76,129,32,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":33},"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,80,145,146,147,148,124,149,150,151,152,122,82,83,153,154,155,156],"analysis","multi","code coverage","campaigns","optimize","crash","parallel","targets","entropy","Optimization","debug","coverage analysis","lldb","target"]