rust-dev-constraints

Enforces ten production Rust constraints for error handling, ownership, unsafe code, and code quality.

Updated May 17, 2026
One-click install
npx skills add https://github.com/irrit-us/agent_misc --skill rust-dev-constraints-irrit-us
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: rust-dev-constraints
Source: https://github.com/irrit-us/agent_misc/tree/main/skills/rust-dev-constraints
Command: npx skills add https://github.com/irrit-us/agent_misc --skill rust-dev-constraints-irrit-us

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Rust codebases accumulate quality issues like panicking .unwrap() calls, unnecessary clones, undocumented unsafe blocks, and monolithic files. This Skill provides a structured rule set of ten production constraints with a decision tree so reviewers and authors apply the right rule at the right time. ## Core Features & Use Cases - Ten Prioritized Constraints: Covers error handling (thiserror/anyhow), ownership and borrowing, unsafe encapsulation, fmt/clippy gates, tracing, 500-line file limits, regression tests, modular design, type safety, and deduplication. - Decision Tree Routing: Maps tasks like PR review, bugfixing, refactoring, and CI setup to the exact reference files that apply. - Bootstrap Order: Provides a nine-step sequence for hardening an existing codebase, starting with fmt/clippy and ending with modular design. - Use Case: When reviewing a Rust PR, follow the decision tree to check for new .unwrap() calls, &Vec<T> signatures, undocumented unsafe blocks, and missing regression tests, then cite the relevant reference file in review comments. ## Quick Start Ask the assistant to review your Rust pull request using the rust-dev-constraints decision tree and report violations of the ten constraints.

Frequently Asked Questions about rust-dev-constraints

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

FAQPage Schema
How do I enforce Rust best practices in code review?▼

Use the decision tree to route each review task to the right constraint file. Every PR baseline checks error handling for .unwrap() additions, ownership for &Vec<T> signatures, and unsafe blocks for documented invariants, with type safety and tracing checks for relevant changes.

Should I use thiserror or anyhow for Rust error handling?▼

Use thiserror for library error types since it derives Display, Error, and From with zero cost. Use anyhow for application code where ergonomic context via .context() and flexible error propagation matter more than typed errors.

When is .unwrap() acceptable in Rust code?▼

The .unwrap() method is acceptable inside #[test] functions and doc examples. In production code, use .expect() only for internal invariants that indicate a bug if violated, and propagate all recoverable errors with Result and the ? operator.

Does the 500-line file limit apply to generated Rust code?▼

Generated code such as protobuf or flatbuffers output is exempt when the generator cannot be configured. Test files may also exceed the limit when readability requires it, and large single-purpose match tables can be documented as exceptions.

How do I audit unsafe Rust code in CI?▼

Run cargo miri test to detect undefined behavior that the compiler cannot catch, and forbid unsafe entirely in safe-only crates with the unsafe_code = "forbid" lint. Every unsafe block must document its safety invariants in comments.