[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6993D6QCQNXP9205MVM8TKB":3,"skill-same:01M6993D6QCQNXP9205MVM8TKB":58},{"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":20,"linkOnly":21,"markdownContent":22,"markdownBody":23,"frontMatter":24,"refName":25,"commitSha":26,"skillDirectory":27,"forksCount":28,"repositoryHtmlUrl":29,"repositoryHomepageUrl":6,"ownerHtmlUrl":30,"ownerBlogUrl":31,"ownerDescription":32,"updatedAt":33,"install":34,"resources":47},"01M6993D6QCQNXP9205MVM8TKB","asset-pipeline",null,"Asset manifests, hash verification, and boot-time resolution for Capsem VM images. Use when debugging boot failures, manifest issues, or hash mismatches.","google\u002Fcapsem","google","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1342004?v=4","01M698VYEFDM0VJBZDYYJ2T83S","Google","01M69939YZJTP726NQK4NZNB48",186,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fcapsem\u002Fblob\u002Fmain\u002Fskills\u002Fasset-pipeline\u002FSKILL.md",[],[19],"asset pipeline","2026-11-10 10:12:30",false,"---\nname: asset-pipeline\ndescription: Asset manifests, hash verification, and boot-time resolution for Capsem VM images. Use when debugging boot failures, manifest issues, or hash mismatches.\n---\n\n# Asset Pipeline\n\nHow VM assets (kernel, initrd, rootfs) are built, checksummed, resolved, and verified at boot.\n\n## Reference routing\n\n- Read `references\u002Fmanifest-and-storage.md` before changing the v2 manifest\n  schema, digest generation or enrichment, corporate\u002Flocal manifest inputs,\n  installed asset layout, package manifest metadata, or cache naming.\n- Read `references\u002Frelease-channel-publication.md` before changing channel\n  graph generation, binary\u002Fruntime publication, channel switching, deployment,\n  Cloudflare readiness, evidence or attestation checks, or cache headers.\n\n## Manifest Authority\n\nThe selected manifest is the bible: if an artifact is not in that manifest, it\ndoes not exist for the release, update, cache, or boot path. Never infer\nmembership from a cache directory, release attachment, filename, channel name,\nor prior run. Fetch mutable manifests fresh. Cache only immutable artifact\nbytes, address each cache entry directly by the digest recorded in the\nmanifest, and re-verify that digest before every use. Artifact cache identity\nis channel-independent; the manifest decides which digest set belongs to a\nchannel at that moment.\n\nFor published application EROFS roots, keep the verified file descriptor through\nkernel loop setup. `mount -o loop \u002Fproc\u002Fself\u002Ffd\u002FN` canonicalizes the name and\nreopens it; a read-only VirtioFS share can deny that second open even while the\nverified descriptor remains readable. The guest launcher uses `LOOP_CONFIGURE`\nwith that descriptor, read-only and auto-clear flags, and a read-only loop handle\nheld through unmount. A writable loop handle conflicts with exclusive mounting.\n`tests\u002Ffixtures\u002Foci\u002Ftest_launch_loop.py` guards descriptor identity and cleanup;\nthe saved-session Ironbank test proves create, reopen, preserved state and resize.\n\n## Versioning\n\nBinary and asset versions are **independent**:\n- **Binary**: `1.3.{unix_timestamp}` on the current release line -- changes every build\n- **Assets**: `YYYY.MMDD.patch` -- changes only on kernel\u002Frootfs\u002Finitrd rebuilds\n\nThe manifest tracks both with compatibility ranges (`min_binary`, `min_assets`).\nRuntime asset selection enforces both directions: older binaries do not hydrate\nasset releases whose `min_binary` requires a newer binary, and new\nsession\u002Fdownload selection skips releases marked `deprecated: true`.\n\n## Key Commands\n\n| Command | When to use |\n|---------|-------------|\n| `just _build-assets` | Full rebuild: kernel + rootfs + checksums (slow, needs docker) |\n| `just shell` | Daily driver: repack initrd, build, sign, boot (~10s) |\n| `just shell \"capsem-doctor\"` | Verify VM boots correctly after changes |\n\nOn macOS, `just _build-assets`, `just _pack-initrd`, and any Docker-backed\nasset recipe depend on Colima. If Docker cannot connect but Colima appears to\nbe running, follow `\u002Fdev-setup`'s Colima recovery discipline before treating\nthe asset build as blocked: check `colima list`, `docker version`, and\n`colima ssh -- docker ps`; then try `colima stop && colima start` once and\nrerun the failing recipe.\n\n## File Locations\n\n| What | Where |\n|------|-------|\n| Runtime source config | `config\u002Fdocker\u002Fimage\u002F` |\n| Guest artifacts | `guest\u002Fartifacts\u002F` |\n| Built assets (dev) | `cache\u002Ftarget\u002Fassets\u002F{arch}\u002Fvmlinuz, initrd.img, rootfs.erofs` |\n| Installed assets | `~\u002F.capsem\u002Fassets\u002F{name}-{hash16}.{ext}` (flat, hash-based) |\n| Manifest | `cache\u002Ftarget\u002Fassets\u002Fmanifest.json` |\n| Asset channel deploy root | `cache\u002Ftarget\u002Frelease\u002Fdistribution\u002F` |\n| Asset channel manifest | `cache\u002Ftarget\u002Frelease\u002Fdistribution\u002Fassets\u002F\u003Cchannel>\u002Fmanifest.json` |\n| Asset channel human site | `build_system\u002Frelease_site\u002F` Astro app, built from `cache\u002Ftarget\u002Frelease\u002Fdistribution\u002F` JSON |\n| Checksums | `cache\u002Ftarget\u002Fassets\u002FB3SUMS` |\n| Manifest generator | `capsem-admin manifest generate \u003Cassets_dir>` |\n| Asset types + cleanup | `crates\u002Fcapsem-core\u002Fsrc\u002Fasset_manager.rs` |\n| Hash extraction for build.rs | `crates\u002Fcapsem-core\u002Fsrc\u002Fmanifest_compat.rs` |\n\n## Boot-Time Resolution\n\n1. **Dev mode**: Service detects arch subdirs, passes `--kernel cache\u002Ftarget\u002Fassets\u002F{arch}\u002Fvmlinuz` etc. to capsem-process\n2. **Installed mode**: Service reads v2 manifest, resolves `ManifestV2::resolve(binary_version, arch, base_dir)` to get hash-based file paths, passes `--kernel`, `--initrd`, `--rootfs` individually to capsem-process\n3. **Hash check at boot**: `VmConfig::builder().build()` verifies BLAKE3 against compile-time hashes if available\n\n## Cleanup\n\n`cleanup_unused_assets(base_dir, manifest)` removes hash-named files not referenced by any non-deprecated asset release. Also removes legacy `v*\u002F` directories.\nExisting VM pins are preserved by the VM pinning rail; deprecation blocks new\nselection rather than rewriting running VMs.\n\nPersistent resume boots the registry entry's own asset pins, never the\ncurrent runtime set. A runtime image advance and a deprecated pin preserve the\nVM; an explicit installed-manifest revocation, a missing pinned asset, invalid\nrootfs geometry, or a registry entry from before profiles were removed blocks\nit. The active policy is re-materialized from current\nsettings and corp config at every boot. Any cached resume verdict must\nfingerprint the installed manifest, rootfs metadata, and pinned asset metadata\nso a revocation or repair is visible immediately.\n\n## Common Issues\n\n**Hash mismatch at boot**: Assets on disk don't match the hashes baked into the binary. Fix: `just shell` (repacks initrd, regenerates manifest, touches build.rs to force recompile).\n\n**Hash mismatch where expected and actual look identical**: the two values differ\nonly by an algorithm tag. Digests reach boot in two spellings — asset manifests\ncarry bare hex, release-graph digests and the runtime pins derived from them\ncarry `blake3:\u003Chex>`.\n\n`VmConfigBuilder::verify_hash` resolves both, in the one place that decides what\nan expected hash means, and refuses a non-blake3 algorithm outright rather than\nletting a `sha256:` pin masquerade as corruption it can never match. Do not add\na second reconciliation at a call site.\n\n**Log pins in full, never truncated.** A 16-character slice renders both\nspellings as plausible prefixes (`blake3:de1d58193` looks like a hash), so a\ntruncated audit line hides exactly the mismatch it exists to catch.\n\n**Boot verifies the *booting runtime's* pins.** The caller passes\n`expected_asset_hashes` for the runtime image set it is starting; nothing\ninfers them from a cache directory or channel name. Absent is a hard error,\nnot permission to boot unverified.\n\n**Hashes silently skipped**: If `build.rs` can't extract hashes (manifest missing, wrong format), `option_env!()` returns `None` and verification is skipped.\n","# Asset Pipeline\n\nHow VM assets (kernel, initrd, rootfs) are built, checksummed, resolved, and verified at boot.\n\n## Reference routing\n\n- Read `references\u002Fmanifest-and-storage.md` before changing the v2 manifest\n  schema, digest generation or enrichment, corporate\u002Flocal manifest inputs,\n  installed asset layout, package manifest metadata, or cache naming.\n- Read `references\u002Frelease-channel-publication.md` before changing channel\n  graph generation, binary\u002Fruntime publication, channel switching, deployment,\n  Cloudflare readiness, evidence or attestation checks, or cache headers.\n\n## Manifest Authority\n\nThe selected manifest is the bible: if an artifact is not in that manifest, it\ndoes not exist for the release, update, cache, or boot path. Never infer\nmembership from a cache directory, release attachment, filename, channel name,\nor prior run. Fetch mutable manifests fresh. Cache only immutable artifact\nbytes, address each cache entry directly by the digest recorded in the\nmanifest, and re-verify that digest before every use. Artifact cache identity\nis channel-independent; the manifest decides which digest set belongs to a\nchannel at that moment.\n\nFor published application EROFS roots, keep the verified file descriptor through\nkernel loop setup. `mount -o loop \u002Fproc\u002Fself\u002Ffd\u002FN` canonicalizes the name and\nreopens it; a read-only VirtioFS share can deny that second open even while the\nverified descriptor remains readable. The guest launcher uses `LOOP_CONFIGURE`\nwith that descriptor, read-only and auto-clear flags, and a read-only loop handle\nheld through unmount. A writable loop handle conflicts with exclusive mounting.\n`tests\u002Ffixtures\u002Foci\u002Ftest_launch_loop.py` guards descriptor identity and cleanup;\nthe saved-session Ironbank test proves create, reopen, preserved state and resize.\n\n## Versioning\n\nBinary and asset versions are **independent**:\n- **Binary**: `1.3.{unix_timestamp}` on the current release line -- changes every build\n- **Assets**: `YYYY.MMDD.patch` -- changes only on kernel\u002Frootfs\u002Finitrd rebuilds\n\nThe manifest tracks both with compatibility ranges (`min_binary`, `min_assets`).\nRuntime asset selection enforces both directions: older binaries do not hydrate\nasset releases whose `min_binary` requires a newer binary, and new\nsession\u002Fdownload selection skips releases marked `deprecated: true`.\n\n## Key Commands\n\n| Command | When to use |\n|---------|-------------|\n| `just _build-assets` | Full rebuild: kernel + rootfs + checksums (slow, needs docker) |\n| `just shell` | Daily driver: repack initrd, build, sign, boot (~10s) |\n| `just shell \"capsem-doctor\"` | Verify VM boots correctly after changes |\n\nOn macOS, `just _build-assets`, `just _pack-initrd`, and any Docker-backed\nasset recipe depend on Colima. If Docker cannot connect but Colima appears to\nbe running, follow `\u002Fdev-setup`'s Colima recovery discipline before treating\nthe asset build as blocked: check `colima list`, `docker version`, and\n`colima ssh -- docker ps`; then try `colima stop && colima start` once and\nrerun the failing recipe.\n\n## File Locations\n\n| What | Where |\n|------|-------|\n| Runtime source config | `config\u002Fdocker\u002Fimage\u002F` |\n| Guest artifacts | `guest\u002Fartifacts\u002F` |\n| Built assets (dev) | `cache\u002Ftarget\u002Fassets\u002F{arch}\u002Fvmlinuz, initrd.img, rootfs.erofs` |\n| Installed assets | `~\u002F.capsem\u002Fassets\u002F{name}-{hash16}.{ext}` (flat, hash-based) |\n| Manifest | `cache\u002Ftarget\u002Fassets\u002Fmanifest.json` |\n| Asset channel deploy root | `cache\u002Ftarget\u002Frelease\u002Fdistribution\u002F` |\n| Asset channel manifest | `cache\u002Ftarget\u002Frelease\u002Fdistribution\u002Fassets\u002F\u003Cchannel>\u002Fmanifest.json` |\n| Asset channel human site | `build_system\u002Frelease_site\u002F` Astro app, built from `cache\u002Ftarget\u002Frelease\u002Fdistribution\u002F` JSON |\n| Checksums | `cache\u002Ftarget\u002Fassets\u002FB3SUMS` |\n| Manifest generator | `capsem-admin manifest generate \u003Cassets_dir>` |\n| Asset types + cleanup | `crates\u002Fcapsem-core\u002Fsrc\u002Fasset_manager.rs` |\n| Hash extraction for build.rs | `crates\u002Fcapsem-core\u002Fsrc\u002Fmanifest_compat.rs` |\n\n## Boot-Time Resolution\n\n1. **Dev mode**: Service detects arch subdirs, passes `--kernel cache\u002Ftarget\u002Fassets\u002F{arch}\u002Fvmlinuz` etc. to capsem-process\n2. **Installed mode**: Service reads v2 manifest, resolves `ManifestV2::resolve(binary_version, arch, base_dir)` to get hash-based file paths, passes `--kernel`, `--initrd`, `--rootfs` individually to capsem-process\n3. **Hash check at boot**: `VmConfig::builder().build()` verifies BLAKE3 against compile-time hashes if available\n\n## Cleanup\n\n`cleanup_unused_assets(base_dir, manifest)` removes hash-named files not referenced by any non-deprecated asset release. Also removes legacy `v*\u002F` directories.\nExisting VM pins are preserved by the VM pinning rail; deprecation blocks new\nselection rather than rewriting running VMs.\n\nPersistent resume boots the registry entry's own asset pins, never the\ncurrent runtime set. A runtime image advance and a deprecated pin preserve the\nVM; an explicit installed-manifest revocation, a missing pinned asset, invalid\nrootfs geometry, or a registry entry from before profiles were removed blocks\nit. The active policy is re-materialized from current\nsettings and corp config at every boot. Any cached resume verdict must\nfingerprint the installed manifest, rootfs metadata, and pinned asset metadata\nso a revocation or repair is visible immediately.\n\n## Common Issues\n\n**Hash mismatch at boot**: Assets on disk don't match the hashes baked into the binary. Fix: `just shell` (repacks initrd, regenerates manifest, touches build.rs to force recompile).\n\n**Hash mismatch where expected and actual look identical**: the two values differ\nonly by an algorithm tag. Digests reach boot in two spellings — asset manifests\ncarry bare hex, release-graph digests and the runtime pins derived from them\ncarry `blake3:\u003Chex>`.\n\n`VmConfigBuilder::verify_hash` resolves both, in the one place that decides what\nan expected hash means, and refuses a non-blake3 algorithm outright rather than\nletting a `sha256:` pin masquerade as corruption it can never match. Do not add\na second reconciliation at a call site.\n\n**Log pins in full, never truncated.** A 16-character slice renders both\nspellings as plausible prefixes (`blake3:de1d58193` looks like a hash), so a\ntruncated audit line hides exactly the mismatch it exists to catch.\n\n**Boot verifies the *booting runtime's* pins.** The caller passes\n`expected_asset_hashes` for the runtime image set it is starting; nothing\ninfers them from a cache directory or channel name. Absent is a hard error,\nnot permission to boot unverified.\n\n**Hashes silently skipped**: If `build.rs` can't extract hashes (manifest missing, wrong format), `option_env!()` returns `None` and verification is skipped.\n",{"name":5,"description":7},"main","d357170bb677125c80cebed720e62bf47bf083ad","skills\u002Fasset-pipeline",26,"https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fcapsem","https:\u002F\u002Fgithub.com\u002Fgoogle","https:\u002F\u002Fopensource.google\u002F","Google ❤️ Open Source","2026-11-14 00:49:59",{"source":8,"skillName":5,"commands":35,"prompt":45,"zipAvailable":46},[36,39,42],{"tool":37,"command":38},"npx","npx skills add google\u002Fcapsem --skill asset-pipeline",{"tool":40,"command":41},"bunx","bunx skills add google\u002Fcapsem --skill asset-pipeline",{"tool":43,"command":44},"pnpm","pnpm dlx skills add google\u002Fcapsem --skill asset-pipeline","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fcapsem\u002Fblob\u002Fmain\u002Fskills\u002Fasset-pipeline\u002FSKILL.md",true,[48,54],{"path":49,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":52,"sourceHtmlUrl":53},"references\u002Fmanifest-and-storage.md","REFERENCE","参考文档",3262,"https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fcapsem\u002Fblob\u002Fmain\u002Fskills\u002Fasset-pipeline\u002Freferences\u002Fmanifest-and-storage.md",{"path":55,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":56,"sourceHtmlUrl":57},"references\u002Frelease-channel-publication.md",8514,"https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fcapsem\u002Fblob\u002Fmain\u002Fskills\u002Fasset-pipeline\u002Freferences\u002Frelease-channel-publication.md",[59,73,89,98,105,112],{"skillNo":60,"name":61,"nameZh":6,"description":62,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":63,"categories":64,"keywords":70,"publishedAt":20},"01M699558T2T4DJMBN08ZCQ79K","use-capsem","Run tasks in Capsem VMs through MCP. Use when an agent needs isolated execution, file analysis, or reports returned to the host.","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fcapsem\u002Fblob\u002Fmain\u002Fskills\u002Fuse-capsem\u002FSKILL.md",[65],{"categoryNo":66,"categoryName":67,"taxonomyType":68,"taxonomyTypeDesc":69},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[71,72],"use capsem","MCP",{"skillNo":74,"name":75,"nameZh":6,"description":76,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":87,"publishedAt":20},"01M69953Z1CSVQ4N07QX529CZY","site-marketing","The marketing website, capsem.org. Use when editing copy, adding sections, or changing the site theme.","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fcapsem\u002Fblob\u002Fmain\u002Fskills\u002Fsite-marketing\u002FSKILL.md",[79,82],{"categoryNo":80,"categoryName":81,"taxonomyType":68,"taxonomyTypeDesc":69},"01JBSEEDCAT000000000000019","营销推广",{"categoryNo":83,"categoryName":84,"taxonomyType":85,"taxonomyTypeDesc":86},"01JBSEEDCAT000000000000035","市场营销","PROFESSION","适用职业",[88],"site marketing",{"skillNo":90,"name":91,"nameZh":6,"description":92,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":93,"categories":94,"keywords":95,"publishedAt":20},"01M69952B33KBBV37N8QTC4191","site-infra","The documentation site, docs.capsem.org. Use for user-directed Diátaxis documentation and Astro Starlight changes.","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fcapsem\u002Fblob\u002Fmain\u002Fskills\u002Fsite-infra\u002FSKILL.md",[],[96,97],"site infra","docs",{"skillNo":99,"name":100,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":101,"categories":102,"keywords":103,"publishedAt":20},"01M69950YKCZKCDB98JDQNBBRJ","site-architecture","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fcapsem\u002Fblob\u002Fmain\u002Fskills\u002Fsite-architecture\u002FSKILL.md",[],[104],"site architecture",{"skillNo":106,"name":107,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":108,"categories":109,"keywords":110,"publishedAt":20},"01M6994Z61JWZ0G2YRJTWFH933","release-process","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fcapsem\u002Fblob\u002Fmain\u002Fskills\u002Frelease-process\u002FSKILL.md",[],[111],"release process",{"skillNo":113,"name":114,"nameZh":6,"description":115,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":116,"categories":117,"keywords":125,"publishedAt":20},"01M6994XKHADM6FBTYTAPG7FYC","meta-skill-creation","Create, improve, and evaluate skills. Use when writing a new skill, editing an existing one, or tuning a description for better triggering.","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fcapsem\u002Fblob\u002Fmain\u002Fskills\u002Fmeta-skill-creation\u002FSKILL.md",[118,121,122],{"categoryNo":119,"categoryName":120,"taxonomyType":68,"taxonomyTypeDesc":69},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":66,"categoryName":67,"taxonomyType":68,"taxonomyTypeDesc":69},{"categoryNo":123,"categoryName":124,"taxonomyType":85,"taxonomyTypeDesc":86},"01JBSEEDCAT000000000000036","内容创作者",[126,127],"meta skill creation","writing"]