rust-review

1# Rust review
2 
3Review Rust code against the same rules the `rust-best-practices` skill uses for writing
4it, and report what to change. The output is a review, not a rewrite: the reader decides
5what to fix. Only rewrite code when the user asks for that.
6 
7## 1. Decide the scope
8 
9- **What to read.** Review exactly what the user pointed at: a file, a module, a crate,
10  or a diff. For a diff, review the changed lines and anything they break, not the whole
11  file.
12- **Library or application.** Check for a `lib.rs`, `pub` items used by other crates, or
13  a published `Cargo.toml`. Library code is held to the API-design rules strictly.
14  Application code gets the simplicity rules instead: concrete types, `anyhow`-style
15  errors, and no speculative generality. Say which you assumed at the top of the report.
16- **The edition and MSRV**, from `Cargo.toml`, so you don't recommend features the
17  project can't use.
18- **Frameworks.** If the crate depends on `bevy` or `bevy_ecs`, read the Bevy digest
19  (`bevy.md`) in the `rust-best-practices` skill's references first. It lists the Bevy
20  conventions to leave alone (by-value system parameters, the prelude, plain-data
21  components) and the ECS bugs to look for.
22 
23## 2. Run the tools first, if you can
24 
25If a Rust toolchain is available, run these from the crate root and fold the results into
26the report. They catch the mechanical issues, which leaves you free for design.
27 
28```bash
29cargo fmt --check
30…