stand-rust
Skill1 starsChanged 10 days agoMITView on GitHub
Rust coding standards. Use when writing Rust code. Covers edition, error handling with thiserror/anyhow, unsafe policy, type patterns, testing, documentation, and dependency management.
In this repository41 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- analyze-codeSkill
- analyze-projectSkill
- analyze-testsSkill
- audit-mergesSkill
- babysit-prSkill
- backlogSkill
- branchSkill
- coderabbitSkill
- commitSkill
- greptileSkill
- implement-issuesSkill
- issueSkill
- jiraSkill
- lintro-addSkill
- lintro-reviewSkill
- lintro-verifySkill
- lintSkill
- properizeSkill
- pr-raycastSkill
- prSkill
- raycastSkill
- rebaseSkill
- reconcileSkill
- scorecardSkill
- stand-ciSkill
- stand-generalSkill
- stand-odinSkill
- stand-pySkill
- stand-tsSkill
- sweep-prsSkill
- test-apiSkill
- test-shellSkill
- testSkill
- test-ui-qsfSkill
- test-uiSkill
- turbo-addSkill
- turbo-testSkill
- turbo-verifySkill
- which-prSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
22 rules. About 0 are common, 5 are distinctive, and 17 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
17
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 15
Use the latest stable edition (2021+)
- Very specific: line 20
Follow the lint skill for formatting and linting — lintro runs rustfmt, clippy, cargo_audit, and cargo_deny as configured
- Very specific: line 22
Treat clippy warnings as errors in CI (-D warnings)
- Very specific: line 27
Use thiserror for library error types — derive structured, typed errors
- Very specific: line 28
Use anyhow for application-level error propagation
- Very specific: line 56
Prefer newtypes for domain concepts — struct UserId(u64) over bare u64
- Very specific: line 57
Use impl Trait in argument position for flexibility.
- Very specific: line 61
Prefer &str over String in function arguments.
- Very specific: line 75
Prefer safe alternatives (e.g., std::sync::Mutex over raw atomics) unless performance demands otherwise
- Very specific: line 97
Use #![deny(missing_docs)] for library crates
- Very specific: line 104
Use #[should_panic(expected = "...")] for expected panics
- Very specific: line 105
Consider proptest or quickcheck for property-based testing where valuable
- Very specific: line 106
Use assert_eq! and assert_ne!
- Distinctive: line 129
Keep the dependency tree minimal — every dependency is an audit and supply chain surface
- Very specific: line 131
Run vulnerability scanning via lintro (uv run lintro chk includes cargo_audit and cargo_deny)
- Distinctive: line 134
Prefer well-maintained crates with active maintainers and good documentation
- Very specific: line 138
Prefer impl blocks over free functions for associated behavior
- Distinctive: line 139
Use the builder pattern for types with many optional fields
- Distinctive: line 140
Prefer iterators and combinators over manual loops where readability permits
- Very specific: line 186
Use #[must_use] on functions whose return value should not be ignored
- Very specific: line 187
Prefer From/Into implementations over ad-hoc conversion methods
- Very specific: line 191
Follow the lint skill for linting and formatting workflow.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Rust Standards
Standards for Rust code.
Edition
- Use the latest stable edition (2021+)
- Set
editionexplicitly inCargo.toml
Toolchain
- Follow the
lintskill for formatting and linting — lintro runsrustfmt,clippy,cargo_audit, andcargo_denyas configured - Treat clippy warnings as errors in CI (
-D warnings) - Customize formatting via
rustfmt.tomlwhere needed
Error Handling
- Use
thiserrorfor library error types — derive structured, typed errors - Use
anyhowfor application-level error propagation - No
.unwrap()in library code — use?or returnResult .expect()only with descriptive messages explaining the invariant:// Good let config = load_config().expect("config.toml must exist at startup"); // Bad let config = load_config().unwrap();- Implement
std::fmt::Displayfor all custom error types Non-panicking
.unwrap_or_default()/.unwrap_or()over trivial-arm matches:// Don't let count = match maybe_count { Some(n) => n, None => 0, }; // Do let count = maybe_count.unwrap_or(0);
Type Patterns
- Prefer newtypes for domain concepts —
struct UserId(u64)over bareu64 - Use
impl Traitin argument position for flexibility; explicit generics in return position for clarity - Derive
Debugon all public types - Derive
Clone,PartialEq,Eq,Hashwhere semantically appropriate - Prefer
&stroverStringin function arguments; returnStringwhen ownership transfers
Unsafe
unsafeblocks MUST include a// SAFETY:comment justifying soundness:// SAFETY: pointer is guaranteed non-null by the allocator contract, // and the lifetime is bounded by the enclosing scope. unsafe { ptr.as_ref() }- Minimize unsafe surface area — encapsulate in safe abstractions
- Prefer safe alternatives (e.g.,
std::sync::Mutexover raw atomics) unless performance demands otherwise
Documentation
///doc comments on all public items (functions, types, traits, modules)Include code examples in doc comments for non-trivial APIs:
/// Parse a duration string like "5s", "100ms", or "2m". /// /// # Examples /// /// ``` /// use mycrate::parse_duration; /// /// let d = parse_duration("5s").unwrap(); /// assert_eq!(d, std::time::Duration::from_secs(5)); /// ``` pub fn parse_duration(s: &str) -> Result<Duration> { ... }- Use
#![deny(missing_docs)]for library crates - Module-level
//!doc comments for crate and module overviews
Testing
- Unit tests in
#[cfg(test)] mod testswithin the same file - Integration tests in
tests/directory - Use
#[should_panic(expected = "...")]for expected panics - Consider
proptestorquickcheckfor property-based testing where valuable - Use
assert_eq!andassert_ne!over bareassert!for better error messages
#[cfg(test)]
mod tests {
use super::*;
#[test]
fn parse_duration_seconds() {
let d = parse_duration("5s").unwrap();
assert_eq!(d, Duration::from_secs(5));
}
#[test]
#[should_panic(expected = "invalid format")]
fn parse_duration_rejects_garbage() {
parse_duration("not_a_duration").unwrap();
}
}Dependencies
- Keep the dependency tree minimal — every dependency is an audit and supply chain surface
- Run vulnerability scanning via lintro (
uv run lintro chkincludescargo_auditandcargo_deny) - Pin versions in workspace
Cargo.tomlfor multi-crate workspaces - Prefer well-maintained crates with active maintainers and good documentation
Patterns
- Prefer
implblocks over free functions for associated behavior - Use the builder pattern for types with many optional fields
- Prefer iterators and combinators over manual loops where readability permits
let-elseover nestedif letpyramids:// Don't if let Some(user) = lookup(id) { if let Some(email) = user.email { send(email); } } // Do let Some(user) = lookup(id) else { return }; let Some(email) = user.email else { return }; send(email);.find()/.position()/.any()over manual index loops:// Don't let mut idx = None; for (i, item) in items.iter().enumerate() { if item.id == target { idx = Some(i); break; } } // Do let idx = items.iter().position(|item| item.id == target);matches!()for pattern booleans:// Don't let is_ready = match state { State::Ready => true, _ => false, }; // Do let is_ready = matches!(state, State::Ready);- Use
#[must_use]on functions whose return value should not be ignored - Prefer
From/Intoimplementations over ad-hoc conversion methods
Linting
Follow the lint skill for linting and formatting workflow.
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
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.

