rust-standards
Skill0 starsChanged yesterdayMITView on GitHub
Rust 2024-edition coding standards, tooling, and crate choices for all projects. Covers workspace layout, determinism, testing, errors, NAPI bindings, and anti-patterns. Load before writing any Rust code.
- Installs packages
3 other projects use a version of this.
Adopted by
Most recently taken up by
- rkdxodud-tyk/SKILLStheir own version, first seen Jul 2, 2026
- motola10/claude-code-basetheir own version, first seen Jun 26, 2026
- kimgoetzke/coding-agent-configstheir own version, first seen Apr 30, 2026
Other versions3 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 3
- kimgoetzke/coding-agent-configs★ 2same name
- motola10/claude-code-base★ 1same name
- rkdxodud-tyk/SKILLS★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository34 other files it gives its agents.
- astroSkill
- bun-standardsSkill
- postgresSkill
- react-engineeringSkill
- spring-bootSkill
- tailwind-v4Skill
- typescript-standardsSkill
- vitest-testingSkill
- api-designSkill
- architecture-reviewSkill
- benchmark-readiness-reviewSkill
- cli-designSkill
- codebase-scoutingSkill
- code-review-findingsSkill
- config-projection-reviewSkill
- documentation-hygieneSkill
- domain-modelingSkill
- formal-verificationSkill
- implementation-planningSkill
- orchestration-workflowSkill
- problem-clarificationSkill
- product-copySkill
- refactorSkill
- repository-text-hygieneSkill
- researchSkill
- security-scope-reviewSkill
- setup-canastaSkill
- system-designSkill
- task-closeoutSkill
- tddSkill
- technical-writingSkill
- upstream-contributionSkill
- writing-issuesSkill
- writing-prSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
14 rules. 0 are common, 5 are distinctive, and 9 are very specific to this project.
0
Common
Most of the 3 edited versions we read keep these.
5
Distinctive
This author's own choices. Worth a look.
9
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 14
Default new projects to it.
- Distinctive: line 22
Keep the core library free of host-binding knowledge (no Node, NAPI or JS in it).
- Very specific: line 31
No wildcard use imports. Always explicit.
- Very specific: line 52
Every source of randomness goes through a single seeded RNG handle passed explicitly.
- Distinctive: line 55
No wall-clock reads in the computation.
- Distinctive: line 66
Default clippy lint level is enough unless a repository opts into more.
- Very specific: line 67
Prefer &str over String in signatures unless ownership is needed.
- Very specific: line 68
Prefer iterators over index loops, and match over nested if let chains.
- Distinctive: line 79
Run benchmarks before and after any hot-path change, and report the delta.
- Very specific: line 91
Use tracing structured events, not println!, in library code.
- Very specific: line 92
Keep hot loops free of logging above trace!
- Very specific: line 98
Use the #[napi] macro; back expensive calls with async thread-pool tasks.
- Very specific: line 99
Prefer Uint8Array / Buffer for large binary payloads over JSON strings.
- Very specific: line 100
Check the generated TypeScript bindings (napi build --dts) into the TS side.
“Common” is measured: kept by at least 6 in 10 of the 3 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Rust Standards (cross-project)
Coding standards, tooling, and crate choices for any project that uses Rust. A repository's own Rust guidance wins where the two differ.
Edition & toolchain
- Rust edition: 2024 (stable since Rust 1.85, the default for
cargo new). Default new projects to it. - Pin the toolchain with
rust-toolchain.tomlat the repo root so everyone builds with the same version. - Target MSRV: latest stable at project start. No nightly features.
Project structure
- Cargo workspace at the repo root, one crate per concern.
- Keep the core library free of host-binding knowledge (no Node, NAPI or JS in it). A separate bridge crate wraps it for the host.
- Integration tests in
tests/(black-box, through the public API), benchmarks inbenches/, runnable dev tools inexamples/.
Module rules
- Public API lives in
lib.rswith explicitpub usere-exports. - Internal modules are
pub(crate)by default. - No wildcard
useimports. Always explicit. - One logical concept per module; split when a file exceeds ~300 lines.
Dependencies
| Crate | Purpose | Note |
serde + serde_json | Serialization | The standard choice |
thiserror | Error types in library code | Idiomatic for libraries |
anyhow | Error context in binaries and examples | Not inside library code |
tracing + tracing-subscriber | Structured logging | Structured, async-ready |
rand + rand_chacha | Seeded RNG when output must be reproducible | ChaCha is deterministic across platforms |
Dev dependencies: criterion (benchmarks), proptest (property tests),
insta (snapshot tests). Add others when a project needs them; do not pull in
a framework (ECS, async runtime, graphics) a project's scale does not need.
Determinism rules
Apply when output must be reproducible (simulation, replay, content hashes):
- Every source of randomness goes through a single seeded RNG handle passed
explicitly. No
thread_rng(). Norand::random(). - The seed is part of the input.
- No wall-clock reads in the computation; model time explicitly.
- No
HashMapiteration-order dependence. UseBTreeMapwhen order matters, or sort keys before iterating. - Floating-point ordering matters. Avoid relying on non-associative FP operations in cross-platform paths.
- A snapshot test pins it: seed X + inputs Y always produce output Z.
Code style
cargo fmton every save.cargo clippy -- -D warningspasses before commit; CI enforces it.- Default clippy lint level is enough unless a repository opts into more.
- Prefer
&stroverStringin signatures unless ownership is needed. - Prefer iterators over index loops, and
matchover nestedif letchains. - Doc comments (
///) on every public item. One-liner minimum. - No
unwrap()orexpect()in library code outside tests and examples. #[must_use]on public constructors whose result can be silently dropped.
Testing standards
- Unit tests live beside the code in
#[cfg(test)] mod tests. - Integration tests in
tests/exercise only the public API. - Property tests (proptest) for invariants the domain guarantees.
- Snapshot tests (insta) where output must stay byte-identical.
- Run benchmarks before and after any hot-path change, and report the delta.
Error handling
- Library code: error enums with
thiserror. Never panic in the public API except for truly unreachable states (unreachable!()with a comment why). - Binaries / examples:
anyhow::Result<()>inmain; convert library errors with?. - Validate at boundaries (public entry points). Trust internal state after.
Logging / tracing
- Use
tracingstructured events, notprintln!, in library code. - Keep hot loops free of logging above
trace!.
NAPI bridge rules
- The bridge crate only wraps library APIs; no domain logic lives there.
crate-type = ["cdylib"]in itsCargo.toml.- Use the
#[napi]macro; back expensive calls with async thread-pool tasks. - Prefer
Uint8Array/Bufferfor large binary payloads over JSON strings. - Check the generated TypeScript bindings (
napi build --dts) into the TS side.
Tooling
rustup default stable
rustup component add rustfmt clippy
cargo install cargo-nextest # faster test runner
cargo install cargo-llvm-cov # coverage
cargo install flamegraph # profiling (requires perf/dtrace)Anti-patterns to never commit
- Wildcard imports (
use foo::*) unwrap()/expect()in non-test library codeBox<dyn Error>in a library instead of a proper error enum- Panics used as control flow
unsafewithout a// SAFETY:comment stating the invariant it relies on
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
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.

