31
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill pplmx/husky-rs --skill rust-expert- SKILL.md1.9 KB
Overview
This skill provides expert guidelines for writing idiomatic, safe, and performant Rust code. It codifies formatting, linting, error handling, testing, and documentation practices tailored for libraries and applications. Use it to enforce consistent, maintainable Rust across projects and hooks.
How this skill works
The skill inspects code patterns and development workflow points to recommend Rust best practices: cargo fmt compliance, clippy-clean code, idiomatic use of Option/Result combinators, and appropriate async boundaries. It also enforces error-handling choices (thiserror vs anyhow), testing placement and strategies, and public API documentation expectations. Apply the guidelines during code review, refactoring, or pre-commit hooks to catch deviations early.
When to use it
- When creating or refactoring library or binary Rust code to improve safety and readability.
- When adding async code that must respect Send bounds and runtime conventions.
- During code reviews to ensure consistent formatting and zero Clippy warnings.
- When establishing project-level standards for testing and documentation.
- When writing public APIs that require clear doc comments and examples.
Best practices
- Always run cargo fmt and fix formatting issues; no custom deviations without config.
- Keep Clippy warning-free; only use #[allow(...)] with a comment explaining why.
- Prefer combinators (map, and_then, unwrap_or_else) and impl Trait to reduce boilerplate.
- Use thiserror for library errors and anyhow for application-level error handling.
- Avoid unwrap()/expect() in production; use ? or document SAFETY: exceptions in tests or invariant code.
- Place unit tests in a tests module, integration tests in tests/, and consider proptest/insta when appropriate.
Example use cases
- Add a new async API in a library and ensure futures are Send when used with tokio runtime.
- Refactor match-heavy transformations into concise Option/Result combinators for readability.
- Design a typestate-based builder to prevent invalid states at compile time.
- Migrate a crate to thiserror for structured error types and update CLI binary to use anyhow.
- Integrate cargo fmt and clippy into pre-commit hooks to block style and lint regressions.
FAQ
Only in tests or when a rigorous invariant guarantees safety; annotate with // SAFETY: and explain the rationale.
Should I always use anyhow for errors?
Use anyhow for application-level code and binaries for ergonomic handling; prefer thiserror for library crates that expose typed errors.