sd-rust-quality

Enforces idiomatic Rust standards for error design, clippy posture, naming, and anti-pattern removal.

Updated Jun 26, 2026
One-click install
npx skills add https://github.com/platypeeps/sd-ai-command-pack --skill sd-rust-quality-platypeeps
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: sd-rust-quality
Source: https://github.com/platypeeps/sd-ai-command-pack/tree/main/contrib/sd-rust-quality
Command: npx skills add https://github.com/platypeeps/sd-ai-command-pack --skill sd-rust-quality-platypeeps

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Rust code written or edited by AI models repeatedly exhibits the same quality failures: clones inserted to satisfy the borrow checker, speculative fallback paths, verbose match chains, and weak error modeling. This Skill holds every Rust change to the idiomatic bar defined by the Rust API guidelines, catching these recurring anti-patterns before they land. ## Core Features & Use Cases - Error type design: Guides deliberate error modeling with concrete enums in libraries (thiserror style), catch-all types at application boundaries (anyhow style), and correct use of #[from] versus .map_err() at public boundaries. - Idiom enforcement: Applies named preferences such as transpose() for Option<Result> conversions, Arc::clone(&x), if let over single-arm match, and newtype wrappers over stringly-typed parameters. - Anti-pattern rejection: Flags borrow-checker-driven clones, single-call-site abstractions, speculative fallbacks, repeated matching on the same value, and transitive-dependency imports. - Use Case: While refactoring a Rust crate, use this Skill to ensure new error enums distinguish actionable failure modes, clippy lints stay at warn in workspace configuration, and every #[allow] carries a written reason. ## Quick Start Use the sd-rust-quality skill to review and improve the Rust code in this crate for idiomatic error handling and clippy conformance.

Frequently Asked Questions about sd-rust-quality

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write idiomatic Rust error types for a library?▼

Libraries should expose concrete error enums in the thiserror style, distinguishing failure modes callers act on differently. Avoid boxed dyn Error in public signatures; convert low-level errors at boundaries with #[from] or .map_err() so they never leak into domain signatures.

What are common Rust anti-patterns to avoid?▼

Common anti-patterns include cloning to satisfy the borrow checker instead of restructuring ownership, speculative fallback paths for failures that never occurred, matching the same value three or more times, and importing crates not listed in [dependencies].

When should I use #[from] versus .map_err() in Rust?▼

Use #[from] when the wrapped source type is one you are willing to publish and version, since it keeps that type in your public contract. Use .map_err() to an owned variant when the source type should not join the crate's public API.

When should I not use this Rust quality skill?▼

Do not use it to model a new type surface, lay out modules and visibility, or structure async code — those belong to dedicated design skills. It also carries no review verdict; it informs authoring rather than judging finished diffs.

How should clippy lints be configured in a Rust workspace?▼

Keep lint groups at warn in workspace configuration and adopt stricter lints progressively. Every #[allow] should carry a written reason or be replaced with #[expect], and lints should never be silenced wholesale to make a diff green.