pplmx/husky-rs
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.
3 skills
This skill helps you write idiomatic, safe Rust by enforcing formatting, error handling, and testing practices across projects.
This skill helps you maintain the husky-rs project by enforcing msrv, build, and release standards across code, tests, and docs.
This skill enforces conventional commits and PR titles in Rust projects, ensuring readable history and machine-parseable metadata.