mcpbeat

Rust Best Practices

apollographql/apollo-mcp-server-rust-best-practices

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

This is a copy. The original lives at comeonoliver/rust-best-practices.

23k tokens
context cost
the whole folder, loaded on every use
10
files
instructions only
0
copies elsewhere
how many repositories repackaged it
301
stars on the repo
on the repository, not the skill itself

Install

one command, takes just this skill from the repository
npx skills add https://github.com/apollographql/apollo-mcp-server --skill rust-best-practices

What comes with it

87 532 bytes besides the instruction
references/chapter_01.md
references/chapter_02.md
references/chapter_03.md
references/chapter_04.md
references/chapter_05.md
references/chapter_06.md
references/chapter_07.md
references/chapter_08.md
references/chapter_09.md

What it tells the agent to use

found in the instruction text
Bash runs shell commands — read the instruction before connecting

The instruction itself

11 sections, as written by the author

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

How to use it

Copy the folder

Take apollographql/apollo-mcp-server-rust-best-practices from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

The agent identifies a skill by the name field in its header. Two skills with the same name cannot sit side by side — one of them will be ignored.