agentleFS
gihwan-devgihwan-dev/claude-code-gui/.agents/skills/rust-best-practices/SKILL.md

rust-best-practices

Skill1 starsChanged 9 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

Used with

Projects with it also use rust-port, inngest and 8 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.
  • weedmoSkill

    rust-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

  • xfstudioSkill

    inngest

    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

  • huialiSkill

    rust-testing

    Also in 7 projects that use this

  • CloudflareSkill

    rust-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

  • mduongvandinhSkill

    go-best-practices

    Also in 3 projects that use this

  • junimnjwSkill

    rust-patterns

    Idiomatic Rust patterns, ownership, error handling, traits, concurrency, and best practices for building safe, performant applications.

    Also in 3 projects that use this

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
  1. Distinctive:

    Before reviewing, familiarize yourself with Apollo's Rust best practices.

    line 25
  2. Very specific:

    Prefer &T over .clone() unless ownership transfer is required

    line 40
  3. Very specific:

    Use &str over String, &[T] over Vec<T> in function parameters

    line 41
  4. Very specific:

    Use Cow<'_, T> when ownership is ambiguous

    line 43
  5. Very specific:

    Never use unwrap()/expect() outside tests

    line 47
  6. Very specific:

    Use thiserror for library errors, anyhow for binaries only

    line 48
  7. Very specific:

    Prefer ? operator over match chains for error propagation

    line 49
  8. Very specific:

    Always benchmark with --release flag

    line 52
  9. Very specific:

    Run cargo clippy -- -D clippy::perf for performance hints

    line 53
  10. Very specific:

    Avoid cloning in loops; use .iter() instead of .into_iter() for Copy types

    line 54
  11. Very specific:

    Prefer iterators over manual loops.

    line 55
  12. Very specific:

    Use #[expect(clippy::lint)] over #[allow(...)] with justification comment.

    line 65
  13. Very specific:

    Use doc tests (///) for public API examples

    line 70
  14. Very specific:

    Consider cargo insta for snapshot testing generated output

    line 71
  15. Distinctive:

    Prefer generics (static dispatch) for performance-critical code

    line 74
  16. Very specific:

    Use dyn Trait only when heterogeneous collections are needed

    line 75
  17. Very specific:

    Every TODO needs a linked issue: // TODO(#42): ...

    line 93

“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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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 &T over .clone() unless ownership transfer is required
  • Use &str over String, &[T] over Vec<T> in function parameters
  • Small Copy types (≤24 bytes) can be passed by value
  • Use Cow<'_, T> when ownership is ambiguous

Error Handling

  • Return Result<T, E> for fallible operations; avoid panic! in production
  • Never use unwrap()/expect() outside tests
  • Use thiserror for library errors, anyhow for binaries only
  • Prefer ? operator over match chains for error propagation

Performance

  • Always benchmark with --release flag
  • Run cargo clippy -- -D clippy::perf for 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 cloning
  • large_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 insta for snapshot testing generated output

Generics & Dispatch

  • Prefer generics (static dispatch) for performance-critical code
  • Use dyn Trait only 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 TODO needs a linked issue: // TODO(#42): ...
  • Enable #![deny(missing_docs)] for libraries

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.