building-rust-crates
Skill111 starsChanged 18 days agoMITView on GitHub
Sets up, tests, and publishes Rust crates — Cargo project layout, a fmt/clippy/test CI gate that actually gates, MSRV pinning, feature-flag hygiene, and crates.io publishing with cargo-release. Use when creating a Rust crate, wiring GitHub Actions for Rust, debugging a clippy or MSRV CI failure, or preparing a crates.io release.
In this repository41 other files it gives its agents.
- building-accessible-interfacesSkill
- wiring-application-configSkill
- shipping-build-artifactsSkill
- permissioning-ci-workflowsSkill
- concurrent-branchesSkill
- shipping-across-surfacesSkill
- writing-defect-reportsSkill
- reporting-derived-metricsSkill
- guarding-destructive-operationsSkill
- running-github-actions-efficientlySkill
- keeping-git-repos-cleanSkill
- designing-interaction-statesSkill
- designing-marketing-pagesSkill
- rendering-untrusted-contentSkill
- reproducing-ci-locallySkill
- running-resumable-sync-jobsSkill
- normalizing-text-for-measurementSkill
- calibrating-thresholds-and-baselinesSkill
- designing-interfacesSkill
- verifying-external-behaviorSkill
- building-go-projectsSkill
- building-browser-extensionsSkill
- designing-python-apisSkill
- building-python-clisSkill
- improving-python-code-qualitySkill
- building-python-communitiesSkill
- documenting-python-librariesSkill
- deferring-heavy-dependenciesSkill
- reviewing-python-librariesSkill
- building-llm-backed-featuresSkill
- building-python-mcp-serversSkill
- packaging-python-librariesSkill
- optimizing-python-performanceSkill
- setting-up-python-librariesSkill
- managing-python-releasesSkill
- auditing-python-securitySkill
- testing-python-librariesSkill
- building-python-web-appsSkill
- building-scala-projectsSkill
- building-swift-appsSkill
- shipping-swift-appsSkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 0 are distinctive, and 5 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈0
Distinctive · estimate
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 40
Keep Cargo.lock out of git for a library, in git for a binary/app.
- Very specific: line 72
If you don't want to maintain an MSRV, delete rust-version rather than let it lie.
- Very specific: line 81
Test the extremes: cargo test --no-default-features and cargo test --all-features.
- Very specific: line 84
Never make one feature silently depend on another's items without declaring it in [features].
- Very specific: line 101
Prefer cargo-release to automate the version bump + tag + publish in one tag-triggered step, mirroring the Python release-automation …
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Building Rust Crates
Starting point. This skill captures the load-bearing Rust project conventions; extend it with reference files (a full
Cargo.toml, a CI workflow, a clippy config) as the patterns firm up, following the same one-owner discipline as the Python skills.
Rust's tooling is unusually good, which makes it easy to ship a crate that compiles but fails other people: a lint gate that only runs locally, an MSRV you advertise but never test, or a feature flag that breaks when a downstream unifies it. The rules below make the gate mean what it says.
Project layout & Cargo.toml essentials
[package]
name = "my-crate"
version = "0.1.0"
edition = "2021" # pin the edition explicitly
rust-version = "1.74" # your MSRV — CI must actually test this
license = "MIT OR Apache-2.0"
description = "One line; required by crates.io"
repository = "https://github.com/owner/my-crate"
[dependencies]
# minimum compatible versions, not exact pins — let downstreams unify
serde = { version = "1", features = ["derive"], optional = true }
[features]
default = []
serde = ["dep:serde"] # gate optional deps behind featuresLibrary code lives in src/lib.rs; a binary in src/main.rs or src/bin/.
Keep Cargo.lock out of git for a library, in git for a binary/app.
The CI gate: fmt + clippy-as-error + test
A green cargo build proves nothing about style or lints. Run all four, and make
clippy warnings fail — otherwise the lint job is decorative:
- uses: dtolnay/rust-toolchain@stable # pin the toolchain, not "latest"
with: { components: rustfmt, clippy }
- run: cargo fmt --all --check # formatting is a gate, not a suggestion
- run: cargo clippy --all-targets --all-features -- -D warnings
- run: cargo test --all-features-D warnings is the load-bearing flag: without it clippy prints warnings and
exits 0, so a "clippy" job stays green while lints pile up. Use --all-features
so feature-gated code is actually compiled and linted.
Test the MSRV you advertise
rust-version in Cargo.toml is a promise. If CI only runs stable, a
dependency bump or a newer-than-MSRV language feature can silently raise your real
minimum while the manifest still claims the old one. Add an MSRV cell that pins
the exact version:
strategy:
matrix:
rust: [stable, "1.74"] # 1.74 == the rust-version in Cargo.tomlIf you don't want to maintain an MSRV, delete rust-version rather than let it
lie.
Feature-flag hygiene
Cargo unifies features across a dependency graph: if any crate in the build
enables your serde feature, it's on for everyone. So every feature combination
must compile on its own and together.
- Test the extremes:
cargo test --no-default-featuresandcargo test --all-features. A--no-default-featuresbuild that fails means a downstream who opts out of your defaults can't use the crate. - Never make one feature silently depend on another's items without declaring it
in
[features]; a downstream enabling only the first gets a compile error.
Don't .unwrap() in library code
.unwrap()/.expect() on a Result/Option in a library turns a recoverable
error into a panic that aborts the caller's process. Return Result with a real
error type (thiserror for libraries, anyhow for binaries) and let the caller
decide. Reserve unwrap for tests and for invariants you've just locally proven.
Publishing to crates.io
cargo publish --dry-run # validates metadata + that it packages cleanly
cargo publish # irreversible: a version can be yanked, never reusedPrefer cargo-release to automate the version bump + tag + publish in one
tag-triggered step, mirroring the Python release-automation pattern. crates.io
enforces semver on the version number but not on your API — bump the major
yourself on a breaking change, and never re-publish a yanked version's number.
Checklist
Rust crate health:
- [ ] edition and rust-version (MSRV) pinned in Cargo.toml
- [ ] license + description + repository set (crates.io requires them)
- [ ] CI runs cargo fmt --check, clippy -D warnings, and test
- [ ] clippy job actually fails on warnings (-D warnings present)
- [ ] MSRV tested as its own matrix cell (or rust-version removed, not left lying)
- [ ] builds with --no-default-features AND --all-features
- [ ] no .unwrap()/.expect() on fallible paths in library code
- [ ] cargo publish --dry-run passes before a real release
- [ ] Cargo.lock committed for a binary, ignored for a libraryDoes it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

