rust-standards
Skill2 starsChanged 7 months agoMITView on GitHub
Write idiomatic Rust code. Use when writing Rust code.
2 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
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 2
- 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 repository23 other files it gives its agents.
- .claude/CLAUDE.mdCLAUDE.md
- .copilot/copilot-instructions.mdCopilot instructions
- ahaSkill
- explain-prSkill
- fetch-planSkill
- generate-pr-descriptionSkill
- grill-meSkill
- improve-a-planSkill
- improve-codebaseSkill
- persistSkill
- planning-modeSkill
- planningSkill
- research-modeSkill
- review-prSkill
- rust-bevy-standardsSkill
- rust-bevy-test-conventionsSkill
- tddSkill
- unslopSkill
- update-agentsSkill
- update-planSkill
- update-skillsSkill
- write-a-skillSkill
- wtfSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
18 rules. About 0 are common, 6 are distinctive, and 12 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈6
Distinctive · estimate
This author's own choices. Worth a look.
12
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 20
Use newtypes: struct Email(String) for domain semantics
- Very specific: line 21
Prefer slice patterns: if let [first, .., last] = slice
- Very specific: line 23
Avoid Vec abuse: use arrays for fixed sizes
- Very specific: line 27
Prefer &str over String in function parameters
- Very specific: line 28
Use String for ownership: return String when transferring ownership
- Very specific: line 29
Prefer bytes: s.bytes() over s.chars() when ASCII
- Very specific: line 30
Use Cow<str> when you might need to modify borrowed data
- Very specific: line 31
Use format! over string concatenation with +
- Very specific: line 32
Avoid nested iteration: contains() on string is O(n\*m)
- Very specific: line 36
Use ? for all fallible operations
- Distinctive: line 57
Don't hold locks across await: use scoped guards
- Distinctive: line 61
Avoid unless necessary: prefer functions/generics
- Distinctive: line 62
Follow Rust syntax: macro input should look like Rust
- Very specific: line 77
Don't restate the name: fn connect() doesn't need "Connects to the server"
- Distinctive: line 78
Document the non-obvious: panics, errors, surprising edge cases.
- Distinctive: line 79
No filler: no "This method...", "Note that...", "Please be aware..."
- Distinctive: line 81
Don't write doctests purely for coverage.
- Very specific: line 95
Use clippy with #![deny(clippy::all, clippy::pedantic)] - fix all warnings
≈ “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
Testing
- Unit tests in
#[cfg(test)]modules within each source file - Integration tests in
tests/directory
Naming
- No
get_prefix:fn name()notfn get_name() - Iterator convention:
iter()/iter_mut()/into_iter() - Conversion naming:
as_(cheap &),to_(expensive),into_(ownership) - Static var prefix:
G_CONFIGforstatic, no prefix forconst
Data Types
- Use newtypes:
struct Email(String)for domain semantics - Prefer slice patterns:
if let [first, .., last] = slice - Pre-allocate:
Vec::with_capacity(),String::with_capacity() - Avoid
Vecabuse: use arrays for fixed sizes
Strings
- Prefer
&stroverStringin function parameters - Use
Stringfor ownership: returnStringwhen transferring ownership - Prefer bytes:
s.bytes()overs.chars()when ASCII - Use
Cow<str>when you might need to modify borrowed data - Use
format!over string concatenation with+ - Avoid nested iteration:
contains()on string is O(n*m)
Error Handling
- Use
?for all fallible operations unwrap()in tests only, never productionexpect()only for provably impossible states; the message must justify why it can't fail e.g.expect("regex is valid: validated at compile time")unwrap_or/unwrap_or_else/unwrap_or_defaultfor deliberate fallbacks- Assertions for invariants:
assert!at function entry
Memory
- Meaningful lifetimes:
'src,'ctxnot just'a try_borrow()for RefCell to avoid panic- Shadowing for transformation:
let x = x.parse()?
Concurrency
- Identify lock ordering to prevent deadlocks
- Atomics for primitives, not Mutex for bool/usize
- Choose memory order carefully: Relaxed/Acquire/Release/SeqCst
Async
- Sync for CPU-bound; async is for I/O
- Don't hold locks across await: use scoped guards
Macros
- Avoid unless necessary: prefer functions/generics
- Follow Rust syntax: macro input should look like Rust
Deprecated → Better
lazy_static!→std::sync::OnceLock(since 1.70)once_cell::Lazy→std::sync::LazyLock(since 1.80)std::sync::mpsc→crossbeam::channelonly if you need multi-consumer or better performance under contention;std::sync::mpscis fine for most use casesfailure/error-chain→thiserror/anyhowtry!()→?operator (since 2018)
Docs
- All
pubmethods must have///doc comments - All
///doc comments must be extremely concise - Imperative mood:
Returns the lengthnotThis function returns the length - Don't restate the name:
fn connect()doesn't need "Connects to the server" - Document the non-obvious: panics, errors, surprising edge cases; skip obvious params/returns
- No filler: no "This method...", "Note that...", "Please be aware..."
# Examplesonly for non-trivial usage; doctests must compile and pass- Don't write doctests purely for coverage; write them only when the example genuinely aids understanding
Quick Reference
Naming: snake_case (fn/var), CamelCase (type), SCREAMING_CASE (const)
Format: rustfmt (just use it)
Docs: /// for public items, //! for module docs
Lint: #![deny(clippy::all, clippy::pedantic)]Miscellaneous
- Derive
Debugon all public types; deriveClone,PartialEqonly when needed - Use clippy with
#![deny(clippy::all, clippy::pedantic)]- fix all warnings - No unsafe blocks
- Modules: one file per module, mod.rs only for re-exports
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.

