rust-best-practices
Skill15 starsChanged 5 months agoMITView on GitHub
Guide for writing idiomatic Rust code based on Apollo GraphQL's best practices handbook. Use this skill when: (1) writing new Rust code or functions, (2) reviewing or refactoring existing Rust code, (3) deciding between borrowing vs cloning or ownership patterns, (4) implementing error handling with Result types, (5) optimizing Rust code for performance, (6) writing tests or documentation for Rust projects.
46 other projects use a version of this, 12 of them edited.
Adopted by
Most recently taken up by
- linx-systems/clamuiedited, first seen Nov 9, 2026
- Cosmian/kmstheir own version, first seen Nov 9, 2026
- dirien/yet-another-agent-harnessword for word, first seen Nov 8, 2026
- crbnos/carbonword for word, first seen Nov 7, 2026
- iyazerski/dev-flows-plugintheir own version, first seen Nov 1, 2026
- MaraniMatias/Musteredited, first seen Nov 1, 2026
Used with
Projects with it also use rust-port, inngest and 6 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
weedmoSkillrust-port
Port an existing codebase or hot path to Rust from any language (Python, C, C++, Go, JS/TS, Java/Kotlin, C#) with an oracle-first workflow: profile to pick targets, freeze equivalence tests before porting, design the FFI boundary, then gate on differential tests and 1-thread vs N-thread release benchmarks. Use when the user asks to rewrite, port, migrate, or speed up code in Rust (PyO3/maturin, napi-rs, jni-rs, cxx, c2rust), or to review such a port.
Also in 4 projects that use this
xfstudioSkillinngest
Inngest expert for serverless-first background jobs, event-driven workflows, and durable execution without managing queues or workers. Use when: inngest, serverless background job, event-driven workflow, step function, durable execution.
Also in 3 projects that use this
CloudflareSkillrust-review
Rust code review for workerd. Covers CXX FFI safety, unsafe code patterns, JSG resource conventions, error handling, and a review checklist adapted from the C++ review skills. Load this skill when reviewing Rust code in src/rust/.
Also in 4 projects that use this
mduongvandinhSkillgo-best-practices
Also in 3 projects that use this
JeffallanSkillrust-engineer
Writes, reviews, and debugs idiomatic Rust code with memory safety and zero-cost abstractions. Implements ownership patterns, manages lifetimes, designs trait hierarchies, builds async applications with tokio, and structures error handling with Result/Option. Use when building Rust applications, solving ownership or borrowing issues, designing trait-based APIs, implementing async/await concurrency, creating FFI bindings, or optimizing for performance and memory safety. Invoke for Rust, Cargo, ownership, borrowing, lifetimes, async Rust, tokio, zero-cost abstractions, memory safety, systems programming.
Also in 3 projects that use this
VercelSkillreact
React renderer for json-render that turns JSON specs into React components. Use when working with @json-render/react, building React UIs from JSON, creating component catalogs, or rendering AI-generated specs.
Also in 3 projects that use this
Other versions46 projects use a version of this.
Word for word · 18
- farm-fe/farm★ 5.6k100% same
- crbnos/carbon★ 2.8k100% same
- openbezal/rhema★ 354100% same
- apollographql/apollo-mcp-server★ 318100% same
- Blushyes/reef★ 84100% same
- microsoft/scope★ 78100% same
- dirien/yet-another-agent-harness★ 19100% same
- elaboration-studio/agentic-hub★ 4100% same
- aphrody-code/bxc★ 2100% same
- broomva/lago★ 2100% same
8 more not listed
Edited · 12
- linx-systems/clamui★ 37297% same
- apollographql/skills★ 12397% same
- kannandreams/agent-top★ 2297% same
- jamesblackwell/falcondeck★ 799% same
- meowdiocre/meowpi★ 387% same
- idexal/idexal-skills★ 297% same
- MaraniMatias/Muster★ 297% same
- Fractal-Tess/agents★ 195% same
- Fractal-Tess/oh-my-pi★ 197% same
- jniltinho/macos-kvm-gui★ 197% same
2 more not listed
Wrote their own version · 16
- morganlinton/BeautifulRust★ 1.8ksame name
- pedronauck/skills★ 649same name
- Cosmian/kms★ 372same name
- baekenough/oh-my-customcode★ 42same name
- tuan3w/herdr-mobile★ 29same name
- ryo-ebata/cc-audit★ 26same name
- mduongvandinh/ai-best-practices-skills★ 18same name
- thrashr888/thrashr888-agent-kit★ 5same name
- fedemelo/agent-config★ 4same name
- kabudu/engineering-agent-skills★ 3same name
6 more not listed
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 repository17 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- cavemanSkill
- create-agentsmdSkill
- diagnoseSkill
- frontend-designSkill
- gpt-image-2Skill
- grill-meSkill
- handoffSkill
- hyperframesSkill
- improve-codebase-architectureSkill
- leptos-guideSkill
- manage-plansSkill
- remotion-best-practicesSkill
- rust-async-patternsSkill
- rust-patternsSkill
- rust-testingSkill
- tauri-v2Skill
The file
Show its rules and text
We split this skill into the rules it gives an agent
17 rules. 0 are common, 2 are distinctive, and 15 are very specific to this project.
0
Common
Most of the 27 edited versions we read keep these.
2
Distinctive
This author's own choices. Worth a look.
15
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 25
Before reviewing, familiarize yourself with Apollo's Rust best practices.
- Very specific: line 40
Prefer &T over .clone() unless ownership transfer is required
- Very specific: line 41
Use &str over String, &[T] over Vec<T> in function parameters
- Very specific: line 43
Use Cow<'_, T> when ownership is ambiguous
- Very specific: line 47
Never use unwrap()/expect() outside tests
- Very specific: line 48
Use thiserror for library errors, anyhow for binaries only
- Very specific: line 49
Prefer ? operator over match chains for error propagation
- Very specific: line 52
Always benchmark with --release flag
- Very specific: line 53
Run cargo clippy -- -D clippy::perf for performance hints
- Very specific: line 54
Avoid cloning in loops; use .iter() instead of .into_iter() for Copy types
- Very specific: line 55
Prefer iterators over manual loops.
- Very specific: line 65
Use #[expect(clippy::lint)] over #[allow(...)] with justification comment.
- Very specific: line 70
Use doc tests (///) for public API examples
- Very specific: line 71
Consider cargo insta for snapshot testing generated output
- Distinctive: line 74
Prefer generics (static dispatch) for performance-critical code
- Very specific: line 75
Use dyn Trait only when heterogeneous collections are needed
- Very specific: line 93
Every TODO needs a linked issue: // TODO(#42): ...
“Common” is measured: kept by at least 6 in 10 of the 27 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 Best Practices
Apply these guidelines when writing or reviewing Rust code. Based on Apollo GraphQL's Rust Best Practices Handbook.
Best Practices Reference
Before reviewing, familiarize yourself with Apollo's Rust best practices. Read ALL relevant chapters in the same turn in parallel. Reference these files when providing feedback:
- Chapter 1 - Coding Styles and Idioms: Borrowing vs cloning, Copy trait, Option/Result handling, iterators, comments
- Chapter 2 - Clippy and Linting: Clippy configuration, important lints, workspace lint setup
- Chapter 3 - Performance Mindset: Profiling, avoiding redundant clones, stack vs heap, zero-cost abstractions
- Chapter 4 - Error Handling: Result vs panic, thiserror vs anyhow, error hierarchies
- Chapter 5 - Automated Testing: Test naming, one assertion per test, snapshot testing
- Chapter 6 - Generics and Dispatch: Static vs dynamic dispatch, trait objects
- Chapter 7 - Type State Pattern: Compile-time state safety, when to use it
- Chapter 8 - Comments vs Documentation: When to comment, doc comments, rustdoc
- Chapter 9 - Understanding Pointers: Thread safety, Send/Sync, pointer types
Quick Reference
Borrowing & Ownership
- Prefer
&Tover.clone()unless ownership transfer is required - Use
&stroverString,&[T]overVec<T>in function parameters - Small
Copytypes (≤24 bytes) can be passed by value - Use
Cow<'_, T>when ownership is ambiguous
Error Handling
- Return
Result<T, E>for fallible operations; avoidpanic!in production - Never use
unwrap()/expect()outside tests - Use
thiserrorfor library errors,anyhowfor binaries only - Prefer
?operator over match chains for error propagation
Performance
- Always benchmark with
--releaseflag - Run
cargo clippy -- -D clippy::perffor performance hints - Avoid cloning in loops; use
.iter()instead of.into_iter()for Copy types - Prefer iterators over manual loops; avoid intermediate
.collect()calls
Linting
Run regularly: cargo clippy --all-targets --all-features --locked -- -D warnings
Key lints to watch:
redundant_clone- unnecessary cloninglarge_enum_variant- oversized variants (consider boxing)needless_collect- premature collection
Use #[expect(clippy::lint)] over #[allow(...)] with justification comment.
Testing
- Name tests descriptively:
process_should_return_error_when_input_empty() - One assertion per test when possible
- Use doc tests (
///) for public API examples - Consider
cargo instafor snapshot testing generated output
Generics & Dispatch
- Prefer generics (static dispatch) for performance-critical code
- Use
dyn Traitonly when heterogeneous collections are needed - Box at API boundaries, not internally
Type State Pattern
Encode valid states in the type system to catch invalid operations at compile time:
struct Connection<State> { /* ... */ _state: PhantomData<State> }
struct Disconnected;
struct Connected;
impl Connection<Connected> {
fn send(&self, data: &[u8]) { /* only connected can send */ }
}Documentation
//comments explain why (safety, workarounds, design rationale)///doc comments explain what and how for public APIs- Every
TODOneeds a linked issue:// TODO(#42): ... - Enable
#![deny(missing_docs)]for libraries
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.

