<< All versions

Skill v1.0.0

currentTrusted Publisher100/100
google/zerocopy/zerocopy-development
──Details
PublishedOctober 2, 2026 at 05:53 AM
Content Hashsha256:c51ff48603ee2f4e...
Git SHA
──Files
Files (1 file, 2.2 KB)
SKILL.md2.2 KBactive
SKILL.md · 52 lines · 2.2 KB

version: "1.0.0" name: zerocopy-development description: >- Develop, modify, build, test, or validate code in google/zerocopy'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.


Zerocopy Development

Apply the repository-scoped instructions for the zerocopy/ subtree in addition to this skill. Commands in this skill assume the working directory is zerocopy/ unless stated otherwise.

Workflow

  1. Inspect the affected implementation, tests, configuration, and nearby

abstractions before changing behavior. Reuse existing utilities and patterns where they fit.

  1. Use ./cargo.sh, never direct cargo. Read

Toolchains and Version Gating when choosing toolchains or changing compiler-version-dependent behavior.

  1. Make the narrowest change that satisfies the task. Keep generated and

handwritten behavior consistent.

  1. If the change authors or modifies unsafe Rust, an unsafe API or trait, raw

pointer or FFI code, safety documentation, a soundness argument, or an invariant-bearing abstraction, also use the sibling unsafe-rust skill. Do not substitute a separate zerocopy-specific unsafe methodology.

  1. Add or update tests at the level that owns the behavior. For UI,

compile-fail, or compiler-output changes, read UI and Output Tests before editing fixtures.

  1. Before submitting, follow

Validation, including the applicable toolchain, feature, and pre-push checks.

Macro Development

Put shared macro logic in src/util/macro_util.rs when doing so avoids repeating generated code. Generated code often triggers lints because names and shapes come from user input; use targeted #[allow(...)] attributes where needed to prevent generated code from producing spurious lint failures.

Commit Messages

Use GitHub issue syntax when a commit resolves or advances an issue:

  • Closes #123 when the commit resolves the issue.
  • Makes progress on #123 when the commit advances but does not resolve it.
All versions