apollographql/skills · Official

rust-best-practices

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.

All-time #1061 Trending #1519 Hot #6027 First seen Jan 26, 2026
8-week activity · all time api

Installation

$ npx skills add apollographql/skills --skill rust-best-practices

Summary

  • Idiomatic Rust coding standards based on Apollo GraphQL's best practices handbook.
  • Covers nine core areas: coding styles and idioms, clippy linting, performance optimization, error handling, testing patterns, generics and dispatch, type state pattern, documentation, and pointer safety Emphasizes borrowing over cloning, Result-based error handling with thiserror/anyhow, and performance profiling with release builds Includes quick reference guidance on ownership patterns, panic avoidance, clippy configuration, test naming conventions, and compile-time state safety via type state pattern Provides specific lints to enforce (redundant_clone, large_enum_variant, needless_collect) and recommends #[expect(...)] over #[allow(...)] with justification comments

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Security audits

Partner security reviews for this skill.

agent-trust-hub SAFE

Analyzed Mar 10, 2026

This skill provides a comprehensive guide for writing idiomatic Rust code based on Apollo GraphQL's best practices handbook. It is an educational resource and contains no malicious instructions or security risks.

snyk LOW

Analyzed Mar 10, 2026

No issues detected.

socket Score 0.9000 · 0 alerts

Analyzed Mar 18, 2026

  • license 1
  • maintenance 1
  • quality 0.9
  • supply chain 1
  • vulnerability 1

0 alerts

Also in this package

Other skills from apollographql/skills · top by installs.

npx skills add apollographql/skills

Browse all from apollographql/skills

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 111
License LICENSE
Default branch main
Open issues 1
Status Active

Skill metadata

Parsed from SKILL.md frontmatter.

Version1.1.1
LicenseMIT
CompatibilityRust 1.70+, Cargo
Allowed toolsBash(cargo:*) Bash(rustc:*) Bash(rustfmt:*) Bash(clippy:*) Read Write Edit Glob Grep
More metadata
author
apollographql
version
1.1.1

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 4,405 B
  • docs SUMMARY.md 436 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 17,700 installs

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](references/chapter_01.md): Borrowing vs cloning, Copy trait, Option/Result handling, iterators, comments, when to extract a function (duplication vs. wrong abstraction)
  • [Chapter 2 - Clippy and Linting](references/chapter_02.md): Clippy configuration, important lints, workspace lint setup
  • [Chapter 3 - Performance Mindset](references/chapter_03.md): Profiling, avoiding redundant clones, stack vs heap, zero-cost abstractions
  • [Chapter 4 - Error Handling](references/chapter_04.md): Result vs panic, thiserror vs anyhow, error hierarchies
  • [Chapter 5 - Automated Testing](references/chapter_05.md): Test naming, one assertion per test, snapshot testing
  • [Chapter 6 - Generics and Dispatch](references/chapter_06.md): Static vs dynamic dispatch, trait objects
  • [Chapter 7 - Type State Pattern](references/chapter_07.md): Compile-time state safety, when to use it
  • [Chapter 8 - Comments vs Documentation](references/chapter_08.md): When to comment, doc comments, rustdoc
  • [Chapter 9 - Understanding Pointers](references/chapter_09.md): 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
  • largeenumvariant - oversized variants (consider boxing)
  • needless_collect - premature collection

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

Testing

  • Name tests descriptively: processshouldreturnerrorwheninputempty()
  • 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