rust-ecosystem

name	Rust Ecosystem
description	This skill should be used when working with Rust projects, "Cargo.toml", "rustc", "cargo build/test/run", "clippy", "rustfmt", or Rust language patterns. Provides comprehensive Rust ecosystem patterns and best practices.

Provide comprehensive patterns for Rust language, Cargo project management, and toolchain configuration. Read - Analyze Cargo.toml and Rust source files Edit - Modify Rust code and Cargo configuration Bash - Run cargo build, cargo test, cargo clippy commands mcp__context7__get-library-docs - Fetch latest Rust documentation Each value has one owner; when owner goes out of scope, value is dropped Immutable (&T) allows multiple borrows; mutable (&mut T) allows exactly one; cannot mix Result for recoverable errors (Ok/Err), Option for optional values (Some/None); use ? for propagation Define behavior with traits; use derive for common implementations (Debug, Clone, PartialEq)

<rust_language> <ownership_borrowing> Each value has exactly one owner. When owner goes out of scope, value is dropped. Use move semantics by default; explicit Clone when needed

Immutable and mutable references with strict rules &T allows multiple simultaneous borrows &mut T allows exactly one mutable borrow Cannot have &mut T while &T exists Lifetime annotations for reference validity Compiler infers lifetimes in common patterns Explicit lifetime annotations for complex cases fn foo<'a>(x: &'a str) -> &'a str { x } 'static for values that live entire program Explicit duplication with .clone() Implicit bitwise copy for simple types Debug formatting with {:?} User-facing formatting with {} Default value construction Equality comparison Ordering comparison Hashing for HashMap/HashSet keys Type conversions Cheap reference conversions Automatically implement common traits #[derive(Debug, Clone, PartialEq, Eq, Hash)] struct MyType { field1: String, field2: i32, }

<error_handling> Recoverable errors with Result with T and E type parameters ? for early return on Err map, and_then, unwrap_or, unwrap_or_else <decision_tree name="when_to_use"> Is this a recoverable error that callers should handle? <if_yes>Return Result type with appropriate error variant</if_yes> <if_no>Use panic only for unrecoverable programming errors</if_no> </decision_tree>

Optional values with Option with T type parameter ? for early return on None map, and_then, unwrap_or, unwrap_or_default Define custom error types with thiserror or anyhow #[derive(Debug, thiserror::Error)] enum MyError { #[error("IO error: {0}")] Io(#[from] std::io::Error), #[error("Parse error: {msg}")] Parse { msg: String }, }

<common_patterns> Fluent API for complex object construction MyStruct::builder() .field1(value1) .field2(value2) .build() <decision_tree name="when_to_use"> Does the struct have many optional fields or complex construction logic? <if_yes>Implement builder pattern for ergonomic construction</if_yes> <if_no>Use simple constructor function or Default trait</if_no> </decision_tree>

Wrapper type for type safety struct UserId(u64); Encode state in type system Prevent invalid state transitions at compile time

<anti_patterns> Using unwrap() in library code Use ? or proper error handling instead

Cloning values unnecessarily Prefer borrowing when possible Using String for all domain values Use enums, newtypes for domain modeling Defaulting to Arc with Mutex with T for concurrency Consider channels or ownership patterns first . ├── Cargo.lock ├── Cargo.toml ├── src/ │ ├── lib.rs # Library crate root │ ├── main.rs # Binary crate root │ └── bin/ # Additional binaries ├── tests/ # Integration tests ├── benches/ # Benchmarks └── examples/ # Example code

<module_organization> src/module/mod.rs with submodules src/module.rs (preferred for simple modules) </module_organization> </project_structure>

<cargo_toml> <basic_structure> [package] name = "my-crate" version = "0.1.0" edition = "2021" # Current edition; edition 2024 (upcoming/future) rust-version = "1.83" # Current stable as of Dec 2025

[dependencies] serde = { version = "1.0", features = ["derive"] }

[dev-dependencies] tokio-test = "0.4"

[build-dependencies] cc = "1.0" </basic_structure>

<feature_flags> [features] default = ["std"] std = [] async = ["tokio"] full = ["std", "async"] </feature_flags>

<profile_optimization> [profile.release] lto = true codegen-units = 1 panic = "abort" strip = true

[profile.dev] opt-level = 0 debug = true </profile_optimization> </cargo_toml>

[workspace] resolver = "2" # Current default for edition 2021; resolver 3 (upcoming, requires Edition 2024) members = ["crate-a", "crate-b"]

[workspace.package] version = "0.1.0" edition = "2021" license = "MIT"

[workspace.dependencies] serde = "1.0" tokio = { version = "1", features = ["full"] } </root_cargo_toml>

<member_inheritance> [package] name = "crate-a" version.workspace = true edition.workspace = true

[dependencies] serde.workspace = true </member_inheritance>

<decision_tree name="when_to_use"> Do you have multiple related crates in one repository? <if_yes>Use workspace to share dependencies and build configuration</if_yes> <if_no>Single crate project without workspace structure</if_no> </decision_tree>

Compile the project Compile with optimizations Build and run binary Run all tests Fast syntax/type check without codegen Generate and open documentation Update dependencies Display dependency tree Rust linter for catching common mistakes and improving code cargo clippy -- -D warnings In Cargo.toml [lints.clippy] pedantic = "warn" nursery = "warn" unwrap_used = "deny" expect_used = "deny"

<file_reference>Or in clippy.toml</file_reference>

msrv = "1.70" cognitive-complexity-threshold = 25

<common_lints> Prefer ? or proper error handling Prefer ? or proper error handling Stricter lints for cleaner code Experimental but useful lints </common_lints>

Automatic code formatter cargo fmt rustfmt.toml edition = "2021" max_width = 100 use_small_heuristics = "Max" imports_granularity = "Crate" group_imports = "StdExternalCrate" reorder_imports = true

<cargo_nextest> Next-generation test runner with better output and parallelism cargo nextest run

Parallel test execution Better failure output JUnit XML output for CI Test retries .config/nextest.toml [profile.default] retries = 2 slow-timeout = { period = "60s", terminate-after = 2 } fail-fast = false

<other_tools> Security vulnerability scanning Dependency license and security checks Check for outdated dependencies Auto-rebuild on file changes Macro expansion debugging </other_tools>

<context7_integration> Use Context7 MCP for up-to-date Rust documentation

<rust_libraries> </rust_libraries>

<usage_patterns> resolve-library-id libraryName="rust lang" get-library-docs context7CompatibleLibraryID="/rust-lang/book" topic="ownership"

get-library-docs context7CompatibleLibraryID="/rust-lang/cargo.git" topic="workspace" get-library-docs context7CompatibleLibraryID="/rust-lang/rust-clippy" topic="lints configuration"

<best_practices> Use cargo check for fast iteration during development Run cargo clippy before committing Format with cargo fmt for consistent style Use workspace for multi-crate projects Prefer &str over String for function parameters Use impl Trait for return types when possible Document public API with /// doc comments Write unit tests alongside code in same file Use integration tests in tests/ for API testing Set rust-version in Cargo.toml for MSRV </best_practices>

Run cargo clippy before committing; fix all warnings Prefer safe Rust over unsafe blocks; document safety invariants when unsafe is needed Use Result and Option types; never unwrap() in library code Use cargo fmt for consistent formatting Prefer &str over String for function parameters Write unit tests in same file, integration tests in tests/ directory Use cargo check for fast iteration during development Understand Rust code requirements 1. Check Cargo.toml for crate configuration 2. Review existing patterns and traits 3. Identify ownership and lifetime requirements Write safe, idiomatic Rust code 1. Design with ownership in mind 2. Use Result/Option for error handling 3. Follow Rust API guidelines Verify Rust code correctness 1. Run cargo check for quick validation 2. Run cargo clippy for lints 3. Run cargo test for testing

<error_escalation> Clippy warning about style Fix warning, maintain idiomatic code Borrow checker error Redesign ownership, avoid unsafe unless necessary Breaking change in public API Stop, present migration options to user Unsafe code without proper justification Block operation, require safe alternatives </error_escalation>

Prefer safe Rust over unsafe blocks Use Result and Option for error handling Follow Rust API guidelines for public APIs Using unwrap() in library code Unnecessary Clone implementations Unsafe code without safety documentation

<related_agents> Ownership architecture, trait design, and type system modeling Rust implementation with proper lifetime management and error handling Run cargo clippy, cargo fmt, and enforce Rust idioms </related_agents>

<related_skills> Navigate trait implementations and module hierarchies Fetch Rust book, cargo, and clippy documentation Debug borrow checker errors, lifetime issues, and performance bottlenecks </related_skills>