rust-expert_skill

This skill helps you write idiomatic, safe Rust by enforcing formatting, error handling, and testing practices across projects.
  • Rust

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.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational