[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M699309SCMH7QEMMT24PDSPC":3,"skill-same:01M699309SCMH7QEMMT24PDSPC":91},{"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":22,"linkOnly":23,"markdownContent":24,"markdownBody":25,"frontMatter":26,"refName":27,"commitSha":28,"skillDirectory":29,"forksCount":30,"repositoryHtmlUrl":31,"repositoryHomepageUrl":32,"ownerHtmlUrl":33,"ownerBlogUrl":34,"ownerDescription":35,"updatedAt":36,"install":37,"resources":50},"01M699309SCMH7QEMMT24PDSPC","unsafe-rust",null,"Author, document, review, audit, or redesign unsafe Rust with proof-grade rigor. Use for unsafe blocks and functions, unsafe traits and impls, raw pointers, FFI, inline assembly, intrinsics, layout or validity reasoning, concurrency and atomics, SIMD and target features, allocators, invariant-bearing fields, safety comments or `# Safety` documentation, soundness reviews, TCB audits, generated unsafe code, changes to safety or behavioral contracts, and proof-oriented redesign of unsafe abstractions.","google\u002Fzerocopy","google","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1342004?v=4","01M698VYEFDM0VJBZDYYJ2T83S","Google","01M6992GNCRKZTS4WF06JZ9HKY",2639,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fzerocopy\u002Fblob\u002Fmain\u002Fevals\u002Funsafe-rust\u002Ffrozen-packages\u002Fd97b9ace50109216614fbb7c975ac9c97508bfa928381d247869699593a2bcdd\u002FSKILL.md",[],[19,20,21],"rust","unsafe rust","review","2026-11-10 10:12:30",false,"---\nname: unsafe-rust\ndescription: \"Author, document, review, audit, or redesign unsafe Rust with proof-grade rigor. Use for unsafe blocks and functions, unsafe traits and impls, raw pointers, FFI, inline assembly, intrinsics, layout or validity reasoning, concurrency and atomics, SIMD and target features, allocators, invariant-bearing fields, safety comments or `# Safety` documentation, soundness reviews, TCB audits, generated unsafe code, changes to safety or behavioral contracts, and proof-oriented redesign of unsafe abstractions.\"\n---\n\n# Unsafe Rust Authoring and Audit\n\nTreat each safety contract as an English-language theorem and each safety\ncomment as its proof. Reject hand-waving, folklore, hidden assumptions, and\nproof by testing.\n\n## Establish the Exact Claim\n\nUnless the user specifies a narrower claim, establish:\n\n> For the exact audited source snapshot, every supported compilation\n> configuration, every valid in-scope use in a context satisfying all\n> out-of-scope safety obligations preserves freedom from Rust undefined behavior\n> under the documented Rust abstract semantics, and every mandatory in-scope\n> documented postcondition holds, assuming only the explicitly recorded trusted\n> computing base (TCB).\n\nInterpret valid use as follows:\n\n- For a safe API, quantify over every well-typed safe use. Impose no hidden\n  safety precondition.\n- For an unsafe API, quantify over every use satisfying all documented initial,\n  ongoing, and terminal safety obligations.\n- For a binary or other entrypoint, quantify over executions satisfying the\n  explicitly recorded deployment assumptions. Do not transfer those\n  assumptions silently to a safe library API.\n\nProve every documented postcondition of each unsafe API in scope and every\ndocumented guarantee consumed by an in-scope soundness proof. Include broader\nsafe-API robustness only when the user or audit scope requests it.\n\nProve source-level Rust soundness first. State claims about a particular\ncompiler backend, binary, platform, security property, probability, or\ndeployment separately with their additional premises.\n\n## Use Only Applicable Premises\n\n- Bottom out Rust-language and standard-library facts in exact applicable text\n  from versioned Rust Reference or standard-library documentation.\n- Quote and link the smallest sufficient set of passages whose propositions,\n  together with justified inference steps, entail the fact. Open each citation\n  and verify its wording, qualifications, version, and scope.\n- Attach an applicability domain to every claim and premise, whether stated\n  locally or inherited from an identified project policy or canonical entry. A\n  derivation proves only the cases covered by all premises it consumes.\n- Apply a guarantee documented for an older Rust release to a later stable\n  release only when an exact applicable Rust backwards-compatibility\n  commitment preserves that exact proposition throughout the later release's\n  relevant domain. An API's stability badge does not by itself preserve every\n  behavioral statement in its current documentation. Record a\n  non-authoritative compatibility premise explicitly in the TCB. Never infer\n  an earlier-version guarantee merely from later documentation.\n- Do not promote this skill, the Rustonomicon, Unsafe Code Guidelines, RFCs,\n  blogs, issue discussions, implementation behavior, Miri, or common practice\n  to Rust axioms. Use them to discover risks and authoritative text, or record\n  the exact additional proposition as a TCB assumption.\n- Trust a deliberately selected safe dependency API to behave as documented\n  only when that exact trust is explicit in the TCB. Do not extend this\n  exception to caller-controlled safe code, callbacks, values, or safe trait\n  implementations.\n- Audit a third-party unsafe API through to admissible premises or record its\n  exact implementation and contract as an additional TCB assumption.\n\nWhen no admissible direct or derived proof can be completed because\nauthoritative documentation is ambiguous or insufficient, identify the\nsmallest missing proposition. Do not repair it with intuition. Report a\ndocumentation gap and suggest an upstream improvement when appropriate.\n\n## Compose Proofs Locally and Literally\n\n- Identify the controlling contract independently of the existing safety\n  comment. Distinguish normative contract text from examples, rationale,\n  implementation comments, and inferred design intent.\n- Read the controlling contract according to its actual text. Decompose every\n  applicable conjunction, implication, quantifier, temporal clause,\n  precondition, and postcondition into separately reviewable obligations. Do\n  not replace a literal requirement with an operationally similar property.\n  Give every normative clause a disposition even when no known consumer uses\n  it.\n- Reify every fact used nonlocally as a named contract or invariant carried by a\n  type, field, function boundary, guard, typestate, lock, token, or other\n  locally checkable mechanism. A function contract about global state is an\n  acceptable degenerate case.\n- Prove that each state transition establishes, preserves, transfers,\n  deliberately suspends under an explicit obligation, or discharges every\n  applicable invariant. At each consumer, prove that the current invariant\n  entails the exact needed precondition.\n- Trace dataflow across calls and time rather than limiting review to lexical\n  unsafe blocks. Account for every producer, transition, and consumer.\n- For new code, place invariant-bearing representation in the smallest\n  practical leaf module, keep safely accessible representation fields private\n  to it, and treat safe code outside that module—including the rest of the same\n  crate—as untrusted.\n\n## Follow the Proof Workflow\n\n1. **Frame the claim.** Record the artifact identity, exact scope, valid uses or\n   executions, Rust and dependency versions, supported configuration set,\n   mandatory postconditions, TCB, exclusions, and whether design alternatives\n   are requested.\n2. **Inventory the surface.** Enumerate every in-scope safe and unsafe API\n   surface, obligation site, invariant producer\u002Ftransition\u002Fconsumer, and\n   generated or expanded artifact across the supported set.\n3. **State every obligation.** Obtain each controlling contract, decompose it\n   literally, and state the exact proposition and applicability to prove.\n4. **Construct the derivation.** Derive every conjunct from checked local facts,\n   named invariants, applicable authoritative axioms, tool-derived theorems, or\n   explicit TCB entries. Unfold definitions and seek indirect multi-premise\n   derivations; absence of one direct sentence is not itself a documentation\n   gap. Justify every intermediate inference.\n5. **Close composition.** Ensure every literal contract clause and safe surface\n   has a disposition, every premise consumed by unsafe code has an admissible\n   source, and every supported configuration region is proved by an abstract\n   argument or exhaustive partition. Try to falsify the contract reading,\n   inference chain, and coverage before concluding `PROVED`.\n6. **Report exactly.** Keep unresolved obligations visible and state the\n   smallest missing implication. Record proofs, TCB, coverage, findings,\n   postcondition failures, documentation gaps, and residual scope without\n   optimism.\n\nDo not require a concrete UB counterexample to reject an incomplete proof. A\nmissing, ambiguous, circular, or inapplicable derivation is sufficient for\n`UNPROVED`.\n\n## Write and Review Proof-Grade Documentation\n\nRead [proof-obligations.md](references\u002Fproof-obligations.md) before authoring or\nreviewing an unsafe contract, invariant, `SAFETY` comment, or local proof.\n\nKeep each proof adjacent to the smallest cohesive unsafe operation or assertion.\nState the exact operation and its preconditions, cite checked facts and named\ninvariants, show the derivation, and prove resulting postconditions and\ninvariant state on every applicable exit.\n\nWhen existing code can be validated only by reconstructing a material\nderivation absent from its safety comment, do not accept it silently. Include\nthe reconstructed derivation—or the smallest missing portion—in the review,\nwith its citations and applicability. Classify implementation correctness\nseparately from proof-documentation quality. If changes are authorized, improve\nthe adjacent proof; otherwise provide proposed wording. Do not use a\nreconstructed implementation proof to invent or strengthen a caller-facing\ncontract retroactively.\n\n## Close API and Configuration Boundaries\n\nRead\n[api-boundaries-and-evolution.md](references\u002Fapi-boundaries-and-evolution.md)\nfor fields, constructors, methods, traits, sealing, macros, public or hidden\nAPIs, robustness, or contract evolution.\n\nApply this mandatory safe-surface checklist: public fields, constructors, safe\nmethods, safe trait methods, and macro-generated APIs all count as safe API\nsurfaces. Include language-reachable `#[doc(hidden)]` safe items for soundness\neven when excluded from documentation or compatibility promises.\n\nTreat caller-provided safe code as adversarial within the behaviors permitted\nby safe Rust and its types. Seal a trait or make it unsafe when soundness\nrequires an unenforced implementer behavior.\n\nRead\n[configurations-and-generated-code.md](references\u002Fconfigurations-and-generated-code.md)\nfor every full audit and whenever conditional compilation, targets, generated\ncode, FFI, assembly, SIMD, allocators, linking, or build tooling is relevant.\nEvery supported combination of compilation options that can ship downstream\nmust be sound. Use parametric proofs or exhaustive partitions when literal\nenumeration would explode; do not substitute a tested sample.\n\n## Evaluate Trust and Evidence\n\nRead [tcb-and-evidence.md](references\u002Ftcb-and-evidence.md) for every full audit\nand whenever a proof uses dependencies, external specifications, tools,\ntesting, formal verification, environmental restrictions, or cryptographic or\nprobabilistic assumptions.\n\nJudge evidence by the exact proposition it establishes, its artifact and model,\nits quantified domain and bounds, its premises, and its residual trust—not by a\nlabel such as testing, static analysis, model checking, or formal verification.\n\n## Design for Provability When Requested\n\nRead [abstraction-design.md](references\u002Fabstraction-design.md) when the user asks\nto design, refactor, or reconsider an unsafe abstraction, or when authoring a\nnew unsafe abstraction.\n\nJudge existing code under its current source and controlling contract. Inferred\nintent or a preferable model may guide a separate proposal but may not narrow,\nreinterpret, or discharge a current obligation. Treat implemented changes as a\nnew artifact and audit them anew.\n\n## Use Exact Verdicts\n\nRead [audit-reporting.md](references\u002Faudit-reporting.md) before delivering a\npersistent or full audit.\n\n- **PROVED:** Every obligation for the exact named claim is discharged over its\n  complete applicability, relative to the stated TCB.\n- **UNPROVED:** At least one required derivation, premise, applicability or\n  coverage argument, postcondition proof, or citation is missing, ambiguous,\n  circular, or unverifiable.\n- **UNSOUND:** A valid use or in-scope execution is proved to reach undefined\n  behavior.\n- **CONTRACT-BROKEN:** A documented postcondition is proved false even though\n  undefined behavior need not occur.\n\nApply verdicts separately to soundness, documented postconditions, and\nconditional application claims. State exact scope, applicability, and TCB\nbeside every verdict. Never substitute “looks sound,” “probably sound,” or test\nsuccess.\n\nFor a persistent audit, complete:\n\n- [tcb-audit-log-template.md](assets\u002Ftcb-audit-log-template.md)\n- [unsafe-code-audit-report-template.md](assets\u002Funsafe-code-audit-report-template.md)\n\nFor an inline review, provide the equivalent material compactly. Reuse an\nexisting canonical project log rather than creating a competing trust model.\n","# Unsafe Rust Authoring and Audit\n\nTreat each safety contract as an English-language theorem and each safety\ncomment as its proof. Reject hand-waving, folklore, hidden assumptions, and\nproof by testing.\n\n## Establish the Exact Claim\n\nUnless the user specifies a narrower claim, establish:\n\n> For the exact audited source snapshot, every supported compilation\n> configuration, every valid in-scope use in a context satisfying all\n> out-of-scope safety obligations preserves freedom from Rust undefined behavior\n> under the documented Rust abstract semantics, and every mandatory in-scope\n> documented postcondition holds, assuming only the explicitly recorded trusted\n> computing base (TCB).\n\nInterpret valid use as follows:\n\n- For a safe API, quantify over every well-typed safe use. Impose no hidden\n  safety precondition.\n- For an unsafe API, quantify over every use satisfying all documented initial,\n  ongoing, and terminal safety obligations.\n- For a binary or other entrypoint, quantify over executions satisfying the\n  explicitly recorded deployment assumptions. Do not transfer those\n  assumptions silently to a safe library API.\n\nProve every documented postcondition of each unsafe API in scope and every\ndocumented guarantee consumed by an in-scope soundness proof. Include broader\nsafe-API robustness only when the user or audit scope requests it.\n\nProve source-level Rust soundness first. State claims about a particular\ncompiler backend, binary, platform, security property, probability, or\ndeployment separately with their additional premises.\n\n## Use Only Applicable Premises\n\n- Bottom out Rust-language and standard-library facts in exact applicable text\n  from versioned Rust Reference or standard-library documentation.\n- Quote and link the smallest sufficient set of passages whose propositions,\n  together with justified inference steps, entail the fact. Open each citation\n  and verify its wording, qualifications, version, and scope.\n- Attach an applicability domain to every claim and premise, whether stated\n  locally or inherited from an identified project policy or canonical entry. A\n  derivation proves only the cases covered by all premises it consumes.\n- Apply a guarantee documented for an older Rust release to a later stable\n  release only when an exact applicable Rust backwards-compatibility\n  commitment preserves that exact proposition throughout the later release's\n  relevant domain. An API's stability badge does not by itself preserve every\n  behavioral statement in its current documentation. Record a\n  non-authoritative compatibility premise explicitly in the TCB. Never infer\n  an earlier-version guarantee merely from later documentation.\n- Do not promote this skill, the Rustonomicon, Unsafe Code Guidelines, RFCs,\n  blogs, issue discussions, implementation behavior, Miri, or common practice\n  to Rust axioms. Use them to discover risks and authoritative text, or record\n  the exact additional proposition as a TCB assumption.\n- Trust a deliberately selected safe dependency API to behave as documented\n  only when that exact trust is explicit in the TCB. Do not extend this\n  exception to caller-controlled safe code, callbacks, values, or safe trait\n  implementations.\n- Audit a third-party unsafe API through to admissible premises or record its\n  exact implementation and contract as an additional TCB assumption.\n\nWhen no admissible direct or derived proof can be completed because\nauthoritative documentation is ambiguous or insufficient, identify the\nsmallest missing proposition. Do not repair it with intuition. Report a\ndocumentation gap and suggest an upstream improvement when appropriate.\n\n## Compose Proofs Locally and Literally\n\n- Identify the controlling contract independently of the existing safety\n  comment. Distinguish normative contract text from examples, rationale,\n  implementation comments, and inferred design intent.\n- Read the controlling contract according to its actual text. Decompose every\n  applicable conjunction, implication, quantifier, temporal clause,\n  precondition, and postcondition into separately reviewable obligations. Do\n  not replace a literal requirement with an operationally similar property.\n  Give every normative clause a disposition even when no known consumer uses\n  it.\n- Reify every fact used nonlocally as a named contract or invariant carried by a\n  type, field, function boundary, guard, typestate, lock, token, or other\n  locally checkable mechanism. A function contract about global state is an\n  acceptable degenerate case.\n- Prove that each state transition establishes, preserves, transfers,\n  deliberately suspends under an explicit obligation, or discharges every\n  applicable invariant. At each consumer, prove that the current invariant\n  entails the exact needed precondition.\n- Trace dataflow across calls and time rather than limiting review to lexical\n  unsafe blocks. Account for every producer, transition, and consumer.\n- For new code, place invariant-bearing representation in the smallest\n  practical leaf module, keep safely accessible representation fields private\n  to it, and treat safe code outside that module—including the rest of the same\n  crate—as untrusted.\n\n## Follow the Proof Workflow\n\n1. **Frame the claim.** Record the artifact identity, exact scope, valid uses or\n   executions, Rust and dependency versions, supported configuration set,\n   mandatory postconditions, TCB, exclusions, and whether design alternatives\n   are requested.\n2. **Inventory the surface.** Enumerate every in-scope safe and unsafe API\n   surface, obligation site, invariant producer\u002Ftransition\u002Fconsumer, and\n   generated or expanded artifact across the supported set.\n3. **State every obligation.** Obtain each controlling contract, decompose it\n   literally, and state the exact proposition and applicability to prove.\n4. **Construct the derivation.** Derive every conjunct from checked local facts,\n   named invariants, applicable authoritative axioms, tool-derived theorems, or\n   explicit TCB entries. Unfold definitions and seek indirect multi-premise\n   derivations; absence of one direct sentence is not itself a documentation\n   gap. Justify every intermediate inference.\n5. **Close composition.** Ensure every literal contract clause and safe surface\n   has a disposition, every premise consumed by unsafe code has an admissible\n   source, and every supported configuration region is proved by an abstract\n   argument or exhaustive partition. Try to falsify the contract reading,\n   inference chain, and coverage before concluding `PROVED`.\n6. **Report exactly.** Keep unresolved obligations visible and state the\n   smallest missing implication. Record proofs, TCB, coverage, findings,\n   postcondition failures, documentation gaps, and residual scope without\n   optimism.\n\nDo not require a concrete UB counterexample to reject an incomplete proof. A\nmissing, ambiguous, circular, or inapplicable derivation is sufficient for\n`UNPROVED`.\n\n## Write and Review Proof-Grade Documentation\n\nRead [proof-obligations.md](references\u002Fproof-obligations.md) before authoring or\nreviewing an unsafe contract, invariant, `SAFETY` comment, or local proof.\n\nKeep each proof adjacent to the smallest cohesive unsafe operation or assertion.\nState the exact operation and its preconditions, cite checked facts and named\ninvariants, show the derivation, and prove resulting postconditions and\ninvariant state on every applicable exit.\n\nWhen existing code can be validated only by reconstructing a material\nderivation absent from its safety comment, do not accept it silently. Include\nthe reconstructed derivation—or the smallest missing portion—in the review,\nwith its citations and applicability. Classify implementation correctness\nseparately from proof-documentation quality. If changes are authorized, improve\nthe adjacent proof; otherwise provide proposed wording. Do not use a\nreconstructed implementation proof to invent or strengthen a caller-facing\ncontract retroactively.\n\n## Close API and Configuration Boundaries\n\nRead\n[api-boundaries-and-evolution.md](references\u002Fapi-boundaries-and-evolution.md)\nfor fields, constructors, methods, traits, sealing, macros, public or hidden\nAPIs, robustness, or contract evolution.\n\nApply this mandatory safe-surface checklist: public fields, constructors, safe\nmethods, safe trait methods, and macro-generated APIs all count as safe API\nsurfaces. Include language-reachable `#[doc(hidden)]` safe items for soundness\neven when excluded from documentation or compatibility promises.\n\nTreat caller-provided safe code as adversarial within the behaviors permitted\nby safe Rust and its types. Seal a trait or make it unsafe when soundness\nrequires an unenforced implementer behavior.\n\nRead\n[configurations-and-generated-code.md](references\u002Fconfigurations-and-generated-code.md)\nfor every full audit and whenever conditional compilation, targets, generated\ncode, FFI, assembly, SIMD, allocators, linking, or build tooling is relevant.\nEvery supported combination of compilation options that can ship downstream\nmust be sound. Use parametric proofs or exhaustive partitions when literal\nenumeration would explode; do not substitute a tested sample.\n\n## Evaluate Trust and Evidence\n\nRead [tcb-and-evidence.md](references\u002Ftcb-and-evidence.md) for every full audit\nand whenever a proof uses dependencies, external specifications, tools,\ntesting, formal verification, environmental restrictions, or cryptographic or\nprobabilistic assumptions.\n\nJudge evidence by the exact proposition it establishes, its artifact and model,\nits quantified domain and bounds, its premises, and its residual trust—not by a\nlabel such as testing, static analysis, model checking, or formal verification.\n\n## Design for Provability When Requested\n\nRead [abstraction-design.md](references\u002Fabstraction-design.md) when the user asks\nto design, refactor, or reconsider an unsafe abstraction, or when authoring a\nnew unsafe abstraction.\n\nJudge existing code under its current source and controlling contract. Inferred\nintent or a preferable model may guide a separate proposal but may not narrow,\nreinterpret, or discharge a current obligation. Treat implemented changes as a\nnew artifact and audit them anew.\n\n## Use Exact Verdicts\n\nRead [audit-reporting.md](references\u002Faudit-reporting.md) before delivering a\npersistent or full audit.\n\n- **PROVED:** Every obligation for the exact named claim is discharged over its\n  complete applicability, relative to the stated TCB.\n- **UNPROVED:** At least one required derivation, premise, applicability or\n  coverage argument, postcondition proof, or citation is missing, ambiguous,\n  circular, or unverifiable.\n- **UNSOUND:** A valid use or in-scope execution is proved to reach undefined\n  behavior.\n- **CONTRACT-BROKEN:** A documented postcondition is proved false even though\n  undefined behavior need not occur.\n\nApply verdicts separately to soundness, documented postconditions, and\nconditional application claims. State exact scope, applicability, and TCB\nbeside every verdict. Never substitute “looks sound,” “probably sound,” or test\nsuccess.\n\nFor a persistent audit, complete:\n\n- [tcb-audit-log-template.md](assets\u002Ftcb-audit-log-template.md)\n- [unsafe-code-audit-report-template.md](assets\u002Funsafe-code-audit-report-template.md)\n\nFor an inline review, provide the equivalent material compactly. Reuse an\nexisting canonical project log rather than creating a competing trust model.\n",{"name":5,"description":7},"main","d19b86bee54a80f957fba6cd536ccaca0df50fb4","evals\u002Funsafe-rust\u002Ffrozen-packages\u002Fd97b9ace50109216614fbb7c975ac9c97508bfa928381d247869699593a2bcdd",194,"https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fzerocopy","https:\u002F\u002Fdiscord.gg\u002FMAvWH2R6zk","https:\u002F\u002Fgithub.com\u002Fgoogle","https:\u002F\u002Fopensource.google\u002F","Google ❤️ Open Source","2026-11-11 08:13:15",{"source":8,"skillName":5,"commands":38,"prompt":48,"zipAvailable":49},[39,42,45],{"tool":40,"command":41},"npx","npx skills add google\u002Fzerocopy --skill unsafe-rust",{"tool":43,"command":44},"bunx","bunx skills add google\u002Fzerocopy --skill unsafe-rust",{"tool":46,"command":47},"pnpm","pnpm dlx skills add google\u002Fzerocopy --skill unsafe-rust","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fzerocopy\u002Fblob\u002Fmain\u002Fevals\u002Funsafe-rust\u002Ffrozen-packages\u002Fd97b9ace50109216614fbb7c975ac9c97508bfa928381d247869699593a2bcdd\u002FSKILL.md",true,[51,57,63,67,71,75,79,83,87],{"path":52,"resourceType":53,"resourceTypeDesc":54,"sizeBytes":55,"sourceHtmlUrl":56},"agents\u002Fopenai.yaml","REFERENCE","参考文档",245,"https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fzerocopy\u002Fblob\u002Fmain\u002Fevals\u002Funsafe-rust\u002Ffrozen-packages\u002Fd97b9ace50109216614fbb7c975ac9c97508bfa928381d247869699593a2bcdd\u002Fagents\u002Fopenai.yaml",{"path":58,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":61,"sourceHtmlUrl":62},"assets\u002Ftcb-audit-log-template.md","ASSET","资产文件",4973,"https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fzerocopy\u002Fblob\u002Fmain\u002Fevals\u002Funsafe-rust\u002Ffrozen-packages\u002Fd97b9ace50109216614fbb7c975ac9c97508bfa928381d247869699593a2bcdd\u002Fassets\u002Ftcb-audit-log-template.md",{"path":64,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":65,"sourceHtmlUrl":66},"assets\u002Funsafe-code-audit-report-template.md",9341,"https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fzerocopy\u002Fblob\u002Fmain\u002Fevals\u002Funsafe-rust\u002Ffrozen-packages\u002Fd97b9ace50109216614fbb7c975ac9c97508bfa928381d247869699593a2bcdd\u002Fassets\u002Funsafe-code-audit-report-template.md",{"path":68,"resourceType":53,"resourceTypeDesc":54,"sizeBytes":69,"sourceHtmlUrl":70},"references\u002Fabstraction-design.md",7611,"https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fzerocopy\u002Fblob\u002Fmain\u002Fevals\u002Funsafe-rust\u002Ffrozen-packages\u002Fd97b9ace50109216614fbb7c975ac9c97508bfa928381d247869699593a2bcdd\u002Freferences\u002Fabstraction-design.md",{"path":72,"resourceType":53,"resourceTypeDesc":54,"sizeBytes":73,"sourceHtmlUrl":74},"references\u002Fapi-boundaries-and-evolution.md",14129,"https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fzerocopy\u002Fblob\u002Fmain\u002Fevals\u002Funsafe-rust\u002Ffrozen-packages\u002Fd97b9ace50109216614fbb7c975ac9c97508bfa928381d247869699593a2bcdd\u002Freferences\u002Fapi-boundaries-and-evolution.md",{"path":76,"resourceType":53,"resourceTypeDesc":54,"sizeBytes":77,"sourceHtmlUrl":78},"references\u002Faudit-reporting.md",8684,"https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fzerocopy\u002Fblob\u002Fmain\u002Fevals\u002Funsafe-rust\u002Ffrozen-packages\u002Fd97b9ace50109216614fbb7c975ac9c97508bfa928381d247869699593a2bcdd\u002Freferences\u002Faudit-reporting.md",{"path":80,"resourceType":53,"resourceTypeDesc":54,"sizeBytes":81,"sourceHtmlUrl":82},"references\u002Fconfigurations-and-generated-code.md",12842,"https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fzerocopy\u002Fblob\u002Fmain\u002Fevals\u002Funsafe-rust\u002Ffrozen-packages\u002Fd97b9ace50109216614fbb7c975ac9c97508bfa928381d247869699593a2bcdd\u002Freferences\u002Fconfigurations-and-generated-code.md",{"path":84,"resourceType":53,"resourceTypeDesc":54,"sizeBytes":85,"sourceHtmlUrl":86},"references\u002Fproof-obligations.md",18310,"https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fzerocopy\u002Fblob\u002Fmain\u002Fevals\u002Funsafe-rust\u002Ffrozen-packages\u002Fd97b9ace50109216614fbb7c975ac9c97508bfa928381d247869699593a2bcdd\u002Freferences\u002Fproof-obligations.md",{"path":88,"resourceType":53,"resourceTypeDesc":54,"sizeBytes":89,"sourceHtmlUrl":90},"references\u002Ftcb-and-evidence.md",14152,"https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fzerocopy\u002Fblob\u002Fmain\u002Fevals\u002Funsafe-rust\u002Ffrozen-packages\u002Fd97b9ace50109216614fbb7c975ac9c97508bfa928381d247869699593a2bcdd\u002Freferences\u002Ftcb-and-evidence.md",[92,101,109,114,120,125],{"skillNo":93,"name":94,"nameZh":6,"description":95,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":96,"categories":97,"keywords":98,"publishedAt":22},"01M699372E24VDMDWYBRJRV1NX","zerocopy-review","Review proposed changes to google\u002Fzerocopy's zerocopy crate and derive crate. Use for pull-request, patch, or diff review where findings should account for zerocopy's correctness, compatibility, testing, maintainability, known merge-blocking placeholders and repository-style requirements.","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fzerocopy\u002Fblob\u002Fmain\u002Fskills\u002Fzerocopy-review\u002FSKILL.md",[],[99,21,100,9],"zerocopy review","testing",{"skillNo":102,"name":103,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":107,"publishedAt":22},"01M699358EH8KJK3M6YZJJCS8Y","zerocopy-development","Develop, modify, build, test, or validate code in google\u002Fzerocopy's zerocopy crate and its derive crate. Use for implementation work, compiler-version gating, generated macro code, UI or compile-fail tests, test placement, linting, feature-gate validation, and pre-submission checks.","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fzerocopy\u002Fblob\u002Fmain\u002Fskills\u002Fzerocopy-development\u002FSKILL.md",[],[108,9],"zerocopy development",{"skillNo":110,"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":111,"categories":112,"keywords":113,"publishedAt":22},"01M69932WHB7A7HQ0VY77XZWP4","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fzerocopy\u002Fblob\u002Fmain\u002Fskills\u002Funsafe-rust\u002FSKILL.md",[],[20,19,21],{"skillNo":115,"name":5,"nameZh":6,"description":116,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":117,"categories":118,"keywords":119,"publishedAt":22},"01M6992Y71RRNKQFDBV9JTJTJ1","Author, document, review, or audit unsafe Rust with proof-grade rigor. Use for unsafe blocks and functions, unsafe traits and impls, raw pointers, FFI, inline assembly, intrinsics, layout or validity reasoning, concurrency and atomics, SIMD and target features, allocators, invariant-bearing fields, safety comments or `# Safety` documentation, soundness reviews, TCB audits, generated unsafe code, and changes to safety or behavioral contracts.","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fzerocopy\u002Fblob\u002Fmain\u002Fevals\u002Funsafe-rust\u002Ffrozen-packages\u002F7ae4d42abd086720ed97bf1ef8b22f66b1d0ed33a0a5834b17eebfdc245c4d52\u002FSKILL.md",[],[20,19,21],{"skillNo":121,"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":122,"categories":123,"keywords":124,"publishedAt":22},"01M6992VWW5M1QWTDXCH381E3V","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fzerocopy\u002Fblob\u002Fmain\u002Fevals\u002Funsafe-rust\u002Ffrozen-packages\u002F6d7e197e431b82eb81dbe7eefc79fde811e0e238435d38c69460cc068e631abb\u002FSKILL.md",[],[20,19,21],{"skillNo":126,"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":127,"categories":128,"keywords":129,"publishedAt":22},"01M6992SJ2691XG6D14D4DN3X1","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fzerocopy\u002Fblob\u002Fmain\u002Fevals\u002Funsafe-rust\u002Ffrozen-packages\u002F668f70202c7bc8f23f7f894fb784a9629fd292c7f6fe69ede815b0e4c10137bf\u002FSKILL.md",[],[19,20,21]]