Use this skill when building, reviewing, or refactoring Rust code that requires strong maintainability discipline: SRP, DRY, OCP, explicit dependency injection, TDD/ATDD workflow, architecture review, and clean project structure. Complements the project's Rust CLAUDE.md with process rigor.
This skill complements CLAUDE.md and .claude/rules/rust-patterns.md. It must stay aligned with both and applies as an execution discipline layer on top of the project's Rust standards.
This skill adds execution rigor:
If CLAUDE.md is stricter on any point, follow CLAUDE.md.
</objective>
<when_to_use> Use this skill when:
Inspect the crate or workspace first.
Read Cargo.toml, local CLAUDE.md, crate layout, feature flags, tool configs, and existing tests.
Define acceptance behavior first. Express the user-visible outcome before writing implementation details.
Add or update an acceptance-level test when the project has that layer. Otherwise, write the closest boundary-level integration test.
Add the next smallest failing test. Prefer a focused unit or module test for the next behavior increment.
Implement the minimum change that makes the test pass. Keep the diff tight. Do not rewrite unrelated code.
Refactor while green. Improve naming, cohesion, dependency flow, and readability without changing behavior.
Keep standards in sync.
If the task materially changes project conventions, architecture, or workflow expectations, update CLAUDE.md or the relevant skill in the same change.
Verify locally. Run formatting, linting, and tests appropriate to the affected crate or workspace.
</process><design_rules> Apply these rules during implementation:
<dependency_injection> Manage code relationships explicitly.
Rust-specific guidance:
Arc only when shared ownership is actually required
</dependency_injection><style_and_readability> Keep the code easy to read and maintain.
let-chains (if let Ok(x) = a && let Some(y) = b { … }), unsafe blocks required inside unsafe fn, stricter impl Trait lifetime capture, gen keyword reservedrustfmt define layout<public_api_rules> Keep public APIs small, intentional, and stable.
#[non_exhaustive] for public enums and structs that are expected to growDeref for wrapper types unless they are genuinely pointer-like
</public_api_rules><testing_discipline> Testing is mandatory.
<comment_rules> Write comments only when they add information the code cannot carry cleanly on its own.
Good comments explain:
unsafeDo not write comments that:
<error_and_type_rules> Keep errors and types strict and readable.
StringResult when callers need failure information and Option only when absence is the whole storyunwrap() or expect() in production code
</error_and_type_rules><concurrency_rules> See CLAUDE.md for the full concurrency rules. Apply this judgment discipline:
<tooling_rules> Verification is part of the implementation, not an optional cleanup step.
cargo fmt --allcargo clippy --all-targets --all-features -- -D warningscargo nextest run (or cargo test if nextest is not installed)cargo test --all-features, cargo test --no-default-features --features vt100-backend, cargo test --doc, and cargo doc --no-deps<review_checklist> Before finishing, verify:
rustfmtunwrap()/expect()<reject_patterns> Reject these patterns:
.await or blocking work inside async tasks<success_criteria> This skill is being followed correctly when:
CLAUDE.md and .claude/rules/