Rust agents need help at decisions the compiler cannot choose for them. A failed borrow can point to an ownership model, a public API needs an error boundary, and concurrent work needs deliberate coordination. Testing, measured performance, and conditional unsafe review add their own evidence loops. Tokio patterns implement runtime-specific async behavior after the coordination architecture is chosen, and runtime safety checks exercise undefined behavior and race paths.
This guide assigns nine source-read Rust workflows distinct jobs across that work. Every description comes from the linked SKILL.md, and install counts are hydrated observations from the skills.sh registry. The count is adoption context; each card explains the actual instructions an agent receives after installation.
How these Rust workflows were picked
Rust scope. Every card guides direct Rust implementation, maintenance, or a clearly scoped common Rust subdomain. Product-specific generators and vendor procedures stay outside this language guide.
Read at the source. The descriptions and highlights follow each linked SKILL.md. Every card keeps that source one click away.
Distinct jobs. Broad quality, ownership diagnostics, error semantics, testing, runtime-neutral concurrency, measured performance, conditional unsafe or FFI review, Tokio async implementation, runtime safety validation have separate decision surfaces.
Dated registry context. Install counts are the August 26, 2026 skills.sh snapshot searched by LazySkills.
Rust workflows at a glance
A comparative index of the top picks. Click any card to navigate directly to its detailed review.
Nine Rust workflows with hydrated install observations from the skills.sh registry.
Language Quality and Core Decisions
Use these first when the task is about the shape and correctness of ordinary Rust code. The broad quality workflow sets the standard; the ownership and error workflows narrow the decision to the compiler or API boundary that needs attention.
rust-best-practices
16.4K installs apollographql
Best for: A general Rust quality pass on implementation and APIs
rust-best-practices packages Apollo GraphQL's Rust Best Practices Handbook into a task-driven guide. It covers coding style, Clippy, performance, errors, tests, dispatch, typestate, documentation, and pointers, with a quick reference that prefers borrowed views when ownership transfer is not required.
Use it for the broad quality pass around a real Rust change: consistent APIs, linting, tests, documentation, and an informed choice between generics and dyn Trait. The focused workflows below are better when the unresolved question is specifically ownership, error semantics, testing, concurrency, performance evidence, or unsafe review.
Apollo handbook chapters selected by task context
Clippy, performance, errors, tests, and documentation guidance
Best for: Moved values, lifetimes, and conflicting borrows
m01-ownership asks who should own a value and for how long instead of treating a compiler diagnostic as a request for a mechanical patch. It maps moved values, short-lived references, and mutable-borrow conflicts to the data model or scope decision behind the error.
The source gives an agent a deliberate menu: move for transfer, &T for a read-only view, &mut T for exclusive mutation, clone when duplication is real, Rc or Arc for the appropriate sharing model, and Cow for conditionally owned data. Use this workflow when ownership is the unresolved part of the change.
Diagnostic-to-design mapping for common ownership errors
Move, borrow, clone, Rc, Arc, and Cow tradeoffs
Scope and mutation questions behind lifetime errors
Escalation from repeated errors to ownership redesign
Best for: Error boundaries and unwrap-heavy Rust code
m06-error-handling separates expected failure from a broken invariant. It assigns normal absence to Option, recoverable failure to Result<T, E>, assertions or panics to cases that should never happen, and caller-owned recovery to ?.
The workflow also distinguishes library and application boundaries: thiserror supports typed library errors, while anyhow supports application-level propagation and context. Choose it when the missing decision is what a caller should receive and recover from, not when the problem is merely a compiler message.
Result, Option, and panic chosen by failure semantics
? propagation and contextual error chains
thiserror for libraries and anyhow for applications
A direct audit path away from routine unwrap calls
These workflows cover evidence and runtime behavior after the core language decisions are clear. Testing verifies behavior, concurrency stays independent of a particular executor, and performance work starts from measurements rather than instinct.
rust-testing
8.6K installs affaan-m
Best for: TDD and coverage for Rust behavior
rust-testing takes a Rust change through red, green, and refactor. Its source places unit tests in cfg(test) modules, integration tests in tests/, async tests under the relevant test attribute, and property checks in proptest. It also covers rstest for parameterized cases and mockall when a trait boundary is the right isolation point.
The workflow reaches past cargo test into doc tests, Criterion benchmarks, cargo-llvm-cov, rustfmt, and Clippy checks in CI. Use it when the desired outcome is verified behavior and a repeatable feedback loop, rather than a runtime safety review or a performance investigation.
Red-green-refactor with cfg(test) modules
Integration, async, property, parameterized, and mocked tests
Best for: Threads, channels, shared state, and synchronization design
m07-concurrency focuses on the boundaries between threads, messages, and shared state. It gives an agent a way to reason about Send and Sync, scoped or spawned work, channels, Mutex and RwLock, atomics, and the ownership consequences of moving data across concurrent tasks.
This is a runtime-neutral concurrency workflow: select the coordination primitive from the workload, shutdown behavior, contention, and data ownership rather than assuming one executor or framework. Use it for synchronization and parallel-work design; use the testing workflow to verify behavior and the performance workflow to measure the result.
Send, Sync, ownership transfer, and scoped work
Threads, channels, shared state, and synchronization primitives
Atomic ordering and contention tradeoffs
Bounded coordination and explicit shutdown decisions
Best for: Hot paths, allocations, throughput, and latency regressions
m10-performance starts with a reproducible measurement and then matches the tool to the suspected cost. It guides an agent through benchmarks, profiling, allocation evidence, compiler output, and release configuration instead of treating every slow operation as a request to clone less or add more concurrency.
The workflow keeps optimization accountable: establish a baseline, identify the hot path or allocation source, make the smallest justified change, and measure again. Install it when a real performance signal exists and the next step needs evidence rather than broad style advice.
Baselines and reproducible benchmark inputs
CPU, allocation, latency, and throughput evidence
Release settings and compiler output as measurement context
Review is a separate workflow, not a default step for every Rust change. Bring it in when the diff crosses an unsafe, raw-pointer, FFI, or similarly security-sensitive boundary that needs deliberate inspection.
rust-review
865 installs trailofbits
Best for: Conditional review of unsafe Rust, raw pointers, and FFI
rust-review is a targeted security review workflow for Rust. It asks an agent to trace unsafe blocks, raw pointers, FFI boundaries, and the invariants that make those operations sound, then inspect callers and failure paths around the boundary.
This card is intentionally conditional. Use it when a change introduces or modifies unsafe code, FFI, manual memory handling, or a security-sensitive Rust boundary. It complements ordinary tests and review; it is not a replacement for the broad quality workflow or a reason to apply a security checklist to safe code with no such boundary.
Unsafe blocks, raw pointers, and FFI boundary tracing
These workflows cover Tokio-specific async implementation and dynamic runtime safety validation. Use Tokio patterns after choosing a runtime-neutral coordination model, and use sanitizers and Miri to exercise safety properties.
rust-async-patterns
17.6K installs wshobson
Best for: Tokio tasks, channels, streams, cancellation, and async diagnostics
rust-async-patterns covers Tokio async implementation patterns through the Future, poll, and waker execution model. It guides tasks, channels, streams, tokio::select!, JoinSet, cancellation tokens, tracing, and Send bounds.
m07-concurrency selects a runtime-neutral coordination model; rust-async-patterns implements Tokio async runtime behavior after that architecture is chosen. The workflow calls out blocking calls and locks held across awaits as hazards to handle in async code.
Future, poll, and waker execution model
Tokio tasks, channels, streams, and tokio::select!
JoinSet, cancellation tokens, tracing, and Send bounds
Best for: Undefined behavior, data races, and runtime safety validation
rust-sanitizers-miri validates Rust runtime safety with nightly AddressSanitizer, ThreadSanitizer, MemorySanitizer, and UndefinedBehaviorSanitizer through RUSTFLAGS. It also covers Miri test and run workflows with MIRIFLAGS.
Use it to interpret sanitizer reports and integrate these checks into CI. rust-review traces unsafe and FFI invariants and misuse paths. General behavior testing verifies expected behavior, while this workflow targets undefined behavior and races.
Nightly ASan, TSan, MSan, and UBSan
RUSTFLAGS and MIRIFLAGS configuration
Miri test and run workflows
Reports, undefined behavior, races, and CI integration
Start with the narrowest decision the task presents. The nine Rust workflows are intentionally distinct: one broad quality pass, three language and feedback decisions, two runtime-neutral concurrency and performance decisions, one conditional safety review, one Tokio async implementation workflow, and one runtime safety validation workflow.
1.Start broad. Use rust-best-practices for the broad quality pass across idioms, linting, APIs, tests, documentation, and performance guidance.
2.Resolve ownership. Pick m01-ownership for moved values, lifetime errors, conflicting borrows, and sharing choices. It turns each diagnostic into an ownership, scope, mutation, or API question.
3.Define errors. Pick m06-error-handling when the unresolved boundary is whether callers receive absence, recoverable failure, context, or an invariant failure.
4.Verify behavior. Use rust-testing for the feedback loop: unit, integration, async, property, parameterized, mocked, documentation, or benchmark tests.
5.Design concurrency. Use m07-concurrency for runtime-neutral choices between threads, channels, shared state, synchronization, atomics, and shutdown behavior.
6.Measure performance. Use m10-performance only after an observed cost. Establish a baseline, measure the suspected hot path or allocation, then validate the optimization with a before-and-after result.
7.Escalate conditionally. Use rust-review when the change crosses an unsafe, raw-pointer, manual-memory, FFI, or security-sensitive boundary. Safe Rust without that boundary does not need this specialized review.
8.Implement Tokio async behavior. Use rust-async-patterns after m07-concurrency has selected a runtime-neutral coordination model. Follow the Future, poll, and waker execution model, then apply Tokio tasks, channels, streams, tokio::select!, JoinSet, cancellation tokens, tracing, and Send bounds while handling blocking calls and locks across awaits.
9.Validate runtime safety. Use rust-sanitizers-miri for nightly ASan, TSan, MSan, UBSan, and Miri test or run checks. Configure RUSTFLAGS and MIRIFLAGS, interpret sanitizer reports, and integrate the checks into CI. rust-review covers unsafe and FFI invariants and misuse paths, while rust-testing covers expected behavior.
Let the compiler narrow the question
Rust diagnostics are unusually useful feedback for an agent because the language rejects a large class of invalid memory and type behavior. A borrow-checker error alone still leaves many legal rewrites. A clone might preserve a confused ownership boundary. An Arc can add atomic costs to data that never crosses a thread. A 'static requirement may reveal that a returned reference should be an owned value instead.
m01-ownership makes that choice explicit before code changes. Its error table associates E0382 with ownership transfer, E0597 with an owner and scope relationship, E0506 with mutation during a borrow, and E0515 with the caller's right to own a return value. Then m06-error-handling asks the matching question for failures: whether absence is normal, recovery belongs to a caller, or an invariant has actually failed. The code can compile after either decision, but only one will explain the API to its next maintainer.
Keep the Rust Core Workflows evidence-led
Testing and performance answer different questions. rust-testing shows whether behavior is correct across the relevant test boundary. The m10-performance workflow starts only when a real cost is visible and asks for a baseline, a targeted measurement, and a before-and-after result. Keeping those outputs separate makes both decisions easier to explain.
rust-review is different again: it is conditional review for unsafe Rust, raw pointers, manual memory handling, FFI, and other security-sensitive boundaries. A normal safe-code change should not be forced through that checklist. Escalate only when the implementation crosses one of those boundaries, then record the invariants and caller assumptions that make the operation sound.
Rust still needs surrounding engineering skills
This language guide focuses on Rust implementation and delivery decisions. The testing and TDD guide adds general behavior-first workflows, and the debugging guide helps when a failing build or runtime scenario needs an evidence-backed root cause.
A review after implementation serves a separate purpose. The code review and refactoring guide covers requirement, architecture, and change inspection beyond the Rust-specific mechanics here. When a Rust service crosses into schema, queries, or migrations, use the databases guide for that boundary.
Keep Rust workflows under control with LazySkills
LazySkills is a terminal UI that scans your machine, shows installed skills with per-agent visibility, diagnoses broken configurations, and searches the same skills.sh registry used for these observations. Install the catalog manager, then choose one of the Rust workflow that fits the decision in front of the agent.
The nine cards cover broad quality with rust-best-practices; ownership with m01-ownership; error semantics with m06-error-handling; behavior feedback with rust-testing; runtime-neutral concurrency with m07-concurrency; measured performance with m10-performance; conditional unsafe or FFI review with rust-review; Tokio async implementation with rust-async-patterns; and runtime safety validation with rust-sanitizers-miri.
Which Rust Core Workflow should handle a moved-value or lifetime error?
Start with m01-ownership. It turns the diagnostic into a question about who owns the data, how long a reference should live, where mutation belongs, and whether sharing is actually needed. Its move, borrow, clone, Rc, Arc, and Cow guidance keeps the fix tied to the intended data model.
When should a Rust Core Workflow choose Result, Option, or panic?
Use m06-error-handling when the unresolved issue is failure semantics. It treats normal absence as Option, recoverable failure as Result<T, E>, and broken invariants as panic or assert. It also separates typed library errors with thiserror from application propagation and context with anyhow.
How are testing, concurrency, and performance separated?
rust-testing establishes expected behavior and repeatable feedback. m07-concurrency chooses runtime-neutral coordination from ownership, contention, and shutdown requirements. rust-async-patterns then implements Tokio runtime behavior, while m10-performance starts only after an observed cost and requires a baseline, a targeted measurement, and a before-and-after result.
When is rust-review needed in the Rust Core Workflows?
Use rust-review conditionally when a change touches unsafe Rust, raw pointers, manual memory handling, FFI, or another security-sensitive boundary. It reviews soundness invariants and misuse paths; safe Rust changes without those boundaries should use the relevant quality, testing, or focused decision workflow instead.
How does rust-sanitizers-miri differ from rust-review and testing?
rust-review traces unsafe and FFI invariants and misuse paths. rust-testing verifies expected behavior. rust-sanitizers-miri runs dynamic nightly sanitizer and Miri checks for undefined behavior and races, interprets their reports, and supports CI integration.
svgdiagram.ai 
