[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6994S0CA5TRTH9YDF6DNVCS":3,"skill-same:01M6994S0CA5TRTH9YDF6DNVCS":54},{"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":26,"linkOnly":27,"markdownContent":28,"markdownBody":29,"frontMatter":30,"refName":31,"commitSha":32,"skillDirectory":33,"forksCount":34,"repositoryHtmlUrl":35,"repositoryHomepageUrl":6,"ownerHtmlUrl":36,"ownerBlogUrl":37,"ownerDescription":38,"updatedAt":39,"install":40,"resources":53},"01M6994S0CA5TRTH9YDF6DNVCS","ironbank",null,"Use when Capsem VM, network, model, MCP, credential broker, security, package-manager, doctor, benchmark, or release-gate behavior needs black-box acceptance proof","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\u002Fironbank\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[5,24,25],"MCP","security","2026-11-10 10:12:30",false,"---\nname: ironbank\ndescription: Use when Capsem VM, network, model, MCP, credential broker, security, package-manager, doctor, benchmark, or release-gate behavior needs black-box acceptance proof\n---\n\n# Ironbank\n\nIronbank is Capsem's full black-box ledger discipline. Use it for release,\nVM, network, model, MCP, credential broker, package-manager, doctor,\nbenchmark, and security acceptance work.\n\n## Core Rule\n\nDo not look at Rust\u002Fproduct internals to decide expected behavior. Ironbank\ntests are written from public contracts, CLI help, docs, route responses,\ngenerated schemas, hermetic fixture definitions, logs, DB rows, and installed\npackage metadata. If the contract is missing, write the RED test for the\nmissing contract.\n\n### Ironbank parity rule\n\nThe Ironbank parity rule is that every portable release gate belongs in\n`just test`. Local `just test` rebuilds both artifact families and runs the\ncomplete recipe. Binary and runtime release CI reuse the same checked-in\nmodules while pulling the unchanged artifact family; green split jobs do not\nreplace those modules. The shared entrypoints include workspace\u002Fruntime tests,\ncoverage floors,\n`capsem-doctor`, Ironbank acceptance, benchmarks, artifact checks, all web\nsurfaces, and Docker\u002Fsystemd Linux install plus a real guest-shell proof. Only\nunavoidable platform boundaries may remain outside, and each must be named\nwith its authoritative final gate.\n\n`just test` is the strict superset of portable CI work. CI workflows may run a\nsmaller relevant slice, but no portable artifact may be built only in workflow\nYAML. In particular, VM asset publication uses the same `just _build-kernel`\nand `just _build-rootfs` primitives owned by `just test` through\n`just _gate-assets`; the canonical gate rebuilds the runtime for arm64 and\nx86_64, validates every required artifact and manifest, and boots each rebuilt\nhost-architecture image to a guest-shell marker. Input-contract tests are not\na substitute for testing the artifact that was actually built.\n\nThe accounting applies to host packages too: macOS-local `just test` must build\nthe real release-mode `.pkg` and both release-mode Linux `.deb` architectures,\nthen execute the production host-SBOM generator over those exact packages.\nLinux-only Rust branches must run locally in Docker as a non-root user through\nthe same checked-in runner used by Linux CI. Generated files must pass a\ngenerate-and-compare idempotence gate; silently refreshing stale outputs is not\na green test.\n\nHardcoded release selection is also unaccounted state. The canonical gate must\nrun the grep-backed selection guard covering public channel names, manifest\nURLs, native postinstall scripts, and both serialized release commands.\nDefaults may be declared explicitly at API boundaries, but downstream channel\nroutes must carry the selected value and damaged packages must fail closed instead of falling back to stable.\n\nFor multi-architecture packages, `required` applies to the package matching the\nrelease host. Cross artifacts are still built and structurally validated,\nbut must not fail early merely because they cannot execute natively on the\nopposite-architecture runner. Tagged arm64 CI must install and verify its exact\npackage\u002Fservice even though that hosted runner lacks KVM; x86_64 CI additionally\nowns the mandatory exact-package guest-shell proof.\n\nAn exact gate that routinely approaches the hosted runner's observed lifetime\nis not release proof. Runtime headroom is part of the ledger: record stage\ndurations, treat repeated same-age termination as a deterministic budget bug,\nand require the expensive production rail to pass locally before spending\nanother CI run. Parallel work is acceptable only when its hidden workspaces,\ncontainer tags, outputs, and cleanup are isolated and covered by a test.\n\nEnforce Docker caches through `\u002Fdev-cache` and the common typed registry before\nconcurrent artifact lanes start. The policy owns each cache's description,\nscope, warm size, maximum size, and prune strategy; acceptance code must not\ninspect Docker's data root or recreate backend-specific capacity logic.\n\n## Required Shape\n\n- Suite home: `tests\u002Fironbank\u002F`.\n- Runner: Python black-box tests through Capsem, `capsem-doctor`, VM sessions,\n  hermetic local services, UDS routes, HTTP routes, logs, and SQLite ledgers.\n- One deterministic stimulus asserts the full path: client result, parsed\n  facts, CEL\u002Fsecurity decision, detection\u002Fenforcement rows, protocol rows,\n  structured logs, status counters, UDS route, HTTP route, and UI JSON shape.\n- Every emitted field is exact-value asserted, typed-invariant asserted, or\n  explicitly marked not applicable.\n- Unknown DB\u002Flog\u002Froute fields fail the test until the field ledger is updated.\n\n## Forbidden\n\n- Rust parser\u002Funit proof as an Ironbank gate.\n- Public-network dependencies.\n- Mocks of the Capsem path.\n- Fallback routes.\n- Status-code-only replay.\n- Row-exists checks.\n- `skip`, `skipif`, `slow`, optional markers, or manual OAuth\u002Fclient dances as\n  release proof.\n\n## Package Managers\n\nInstalling is not proof. For apt, npm, uv, pip, node, or OCI image package\nrails, assert binary presence\u002Fversion\u002Fhash where relevant and run a command\nthat proves the package does its job. Example: `zstd` must compress and\ndecompress known bytes and match the original.\n","# Ironbank\n\nIronbank is Capsem's full black-box ledger discipline. Use it for release,\nVM, network, model, MCP, credential broker, package-manager, doctor,\nbenchmark, and security acceptance work.\n\n## Core Rule\n\nDo not look at Rust\u002Fproduct internals to decide expected behavior. Ironbank\ntests are written from public contracts, CLI help, docs, route responses,\ngenerated schemas, hermetic fixture definitions, logs, DB rows, and installed\npackage metadata. If the contract is missing, write the RED test for the\nmissing contract.\n\n### Ironbank parity rule\n\nThe Ironbank parity rule is that every portable release gate belongs in\n`just test`. Local `just test` rebuilds both artifact families and runs the\ncomplete recipe. Binary and runtime release CI reuse the same checked-in\nmodules while pulling the unchanged artifact family; green split jobs do not\nreplace those modules. The shared entrypoints include workspace\u002Fruntime tests,\ncoverage floors,\n`capsem-doctor`, Ironbank acceptance, benchmarks, artifact checks, all web\nsurfaces, and Docker\u002Fsystemd Linux install plus a real guest-shell proof. Only\nunavoidable platform boundaries may remain outside, and each must be named\nwith its authoritative final gate.\n\n`just test` is the strict superset of portable CI work. CI workflows may run a\nsmaller relevant slice, but no portable artifact may be built only in workflow\nYAML. In particular, VM asset publication uses the same `just _build-kernel`\nand `just _build-rootfs` primitives owned by `just test` through\n`just _gate-assets`; the canonical gate rebuilds the runtime for arm64 and\nx86_64, validates every required artifact and manifest, and boots each rebuilt\nhost-architecture image to a guest-shell marker. Input-contract tests are not\na substitute for testing the artifact that was actually built.\n\nThe accounting applies to host packages too: macOS-local `just test` must build\nthe real release-mode `.pkg` and both release-mode Linux `.deb` architectures,\nthen execute the production host-SBOM generator over those exact packages.\nLinux-only Rust branches must run locally in Docker as a non-root user through\nthe same checked-in runner used by Linux CI. Generated files must pass a\ngenerate-and-compare idempotence gate; silently refreshing stale outputs is not\na green test.\n\nHardcoded release selection is also unaccounted state. The canonical gate must\nrun the grep-backed selection guard covering public channel names, manifest\nURLs, native postinstall scripts, and both serialized release commands.\nDefaults may be declared explicitly at API boundaries, but downstream channel\nroutes must carry the selected value and damaged packages must fail closed instead of falling back to stable.\n\nFor multi-architecture packages, `required` applies to the package matching the\nrelease host. Cross artifacts are still built and structurally validated,\nbut must not fail early merely because they cannot execute natively on the\nopposite-architecture runner. Tagged arm64 CI must install and verify its exact\npackage\u002Fservice even though that hosted runner lacks KVM; x86_64 CI additionally\nowns the mandatory exact-package guest-shell proof.\n\nAn exact gate that routinely approaches the hosted runner's observed lifetime\nis not release proof. Runtime headroom is part of the ledger: record stage\ndurations, treat repeated same-age termination as a deterministic budget bug,\nand require the expensive production rail to pass locally before spending\nanother CI run. Parallel work is acceptable only when its hidden workspaces,\ncontainer tags, outputs, and cleanup are isolated and covered by a test.\n\nEnforce Docker caches through `\u002Fdev-cache` and the common typed registry before\nconcurrent artifact lanes start. The policy owns each cache's description,\nscope, warm size, maximum size, and prune strategy; acceptance code must not\ninspect Docker's data root or recreate backend-specific capacity logic.\n\n## Required Shape\n\n- Suite home: `tests\u002Fironbank\u002F`.\n- Runner: Python black-box tests through Capsem, `capsem-doctor`, VM sessions,\n  hermetic local services, UDS routes, HTTP routes, logs, and SQLite ledgers.\n- One deterministic stimulus asserts the full path: client result, parsed\n  facts, CEL\u002Fsecurity decision, detection\u002Fenforcement rows, protocol rows,\n  structured logs, status counters, UDS route, HTTP route, and UI JSON shape.\n- Every emitted field is exact-value asserted, typed-invariant asserted, or\n  explicitly marked not applicable.\n- Unknown DB\u002Flog\u002Froute fields fail the test until the field ledger is updated.\n\n## Forbidden\n\n- Rust parser\u002Funit proof as an Ironbank gate.\n- Public-network dependencies.\n- Mocks of the Capsem path.\n- Fallback routes.\n- Status-code-only replay.\n- Row-exists checks.\n- `skip`, `skipif`, `slow`, optional markers, or manual OAuth\u002Fclient dances as\n  release proof.\n\n## Package Managers\n\nInstalling is not proof. For apt, npm, uv, pip, node, or OCI image package\nrails, assert binary presence\u002Fversion\u002Fhash where relevant and run a command\nthat proves the package does its job. Example: `zstd` must compress and\ndecompress known bytes and match the original.\n",{"name":5,"description":7},"main","d357170bb677125c80cebed720e62bf47bf083ad","skills\u002Fironbank",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":41,"prompt":51,"zipAvailable":52},[42,45,48],{"tool":43,"command":44},"npx","npx skills add google\u002Fcapsem --skill ironbank",{"tool":46,"command":47},"bunx","bunx skills add google\u002Fcapsem --skill ironbank",{"tool":49,"command":50},"pnpm","pnpm dlx skills add google\u002Fcapsem --skill ironbank","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fcapsem\u002Fblob\u002Fmain\u002Fskills\u002Fironbank\u002FSKILL.md",true,[],[55,64,80,89,96,103],{"skillNo":56,"name":57,"nameZh":6,"description":58,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":59,"categories":60,"keywords":62,"publishedAt":26},"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",[61],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[63,24],"use capsem",{"skillNo":65,"name":66,"nameZh":6,"description":67,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":68,"categories":69,"keywords":78,"publishedAt":26},"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",[70,73],{"categoryNo":71,"categoryName":72,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000019","营销推广",{"categoryNo":74,"categoryName":75,"taxonomyType":76,"taxonomyTypeDesc":77},"01JBSEEDCAT000000000000035","市场营销","PROFESSION","适用职业",[79],"site marketing",{"skillNo":81,"name":82,"nameZh":6,"description":83,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":84,"categories":85,"keywords":86,"publishedAt":26},"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",[],[87,88],"site infra","docs",{"skillNo":90,"name":91,"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":92,"categories":93,"keywords":94,"publishedAt":26},"01M69950YKCZKCDB98JDQNBBRJ","site-architecture","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fcapsem\u002Fblob\u002Fmain\u002Fskills\u002Fsite-architecture\u002FSKILL.md",[],[95],"site architecture",{"skillNo":97,"name":98,"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":99,"categories":100,"keywords":101,"publishedAt":26},"01M6994Z61JWZ0G2YRJTWFH933","release-process","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fcapsem\u002Fblob\u002Fmain\u002Fskills\u002Frelease-process\u002FSKILL.md",[],[102],"release process",{"skillNo":104,"name":105,"nameZh":6,"description":106,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":107,"categories":108,"keywords":116,"publishedAt":26},"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",[109,112,113],{"categoryNo":110,"categoryName":111,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":114,"categoryName":115,"taxonomyType":76,"taxonomyTypeDesc":77},"01JBSEEDCAT000000000000036","内容创作者",[117,118],"meta skill creation","writing"]