Write Idiomatic Rust

Prioritize the user's request, project instructions, existing conventions, compatibility, and supported toolchain. Hold public and internal code to the same standards of readability, predictability, type safety, and maintainability, but apply rules about downstream compatibility, publishing, or public documentation only to public surfaces.

Keep work scoped to the task. Add a helper, trait, type, or module only when it provides a concrete benefit to responsibility, ownership, type safety, or current duplication. Before building general-purpose utilities or repetitive infrastructure, follow Dependency selection; minimize total maintenance cost, not dependency count alone.

Workflow

1. Inspect the relevant Cargo.toml, workspace structure, edition, rust-version, features, no_std support, dependencies, nearby code, and tests. Do not inventory unrelated parts of the project.
2. Identify the concrete decisions introduced by the task: affected APIs and types, ownership and error boundaries, construction paths, function or method placement, compatibility constraints, and validation needs.
3. Use Reference routing below to choose one primary guide per concrete decision. Open the relevant upstream section, and stop when the decision is resolved. Follow a secondary reference only for an unresolved question or a distinct decision. Record applicable guidance and material deviations; do not enumerate irrelevant rules.
4. Implement or recommend the smallest design that preserves behavior and compatibility while keeping responsibility, data flow, and ownership locally understandable. State the impact and migration path for any required breaking change.
5. Validate according to task type:
   • Pass --message-format=short to cargo bench, build, check, doc, fix, install, run, rustc, rustdoc, and test.
   • For an implementation, fix, or refactor that changes the Rust project, run <skill-root>/scripts/strict-clippy.sh from the target project's root with the needed package, target, and feature options. Then run the project's normal Clippy command and its required formatting, tests, and supported feature or target checks. Follow Clippy policy.
   • For a review without code changes, run targeted non-mutating diagnostics only when they materially support the review; strict Clippy is optional unless the user or project requires it.
   • For design advice or explanation without project changes, do not run validation commands unless they are needed to answer accurately.
   • Keep validation proportional to the affected scope. Report blocked checks and unrelated or pre-existing failures instead of expanding the task to fix them.