# Rust Review

Review existing Rust code for idiom, API design, error handling, safety, and...

- Repository: https://github.com/morganlinton/BeautifulRust (1642 stars)
- Category: Design
- License: MIT
- Last updated: 2026-10-30
- Runs scripts: yes, review before use

## Install

Claude Code: `npx skills add morganlinton/BeautifulRust --skill rust-review -g -a claude-code -y`
Codex: `npx skills add morganlinton/BeautifulRust --skill rust-review -g -a codex -y`
Cursor: `npx skills add morganlinton/BeautifulRust --skill rust-review -g -a cursor -y`
Gemini CLI: `npx skills add morganlinton/BeautifulRust --skill rust-review -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add morganlinton/BeautifulRust`

## Description

Review existing Rust code for idiom, API design, error handling, safety, and maintainability, and produce a prioritized report where every finding cites the rule it breaks and gives a concrete fix. Use this whenever the user asks to review, audit, critique, grade, or "check" Rust code, a crate, a module, a .rs file, a diff, or a pull request, or asks what is wrong with their Rust or how to make it more idiomatic, even if they don't say "review". Pairs with the rust-best-practices skill, which covers writing new code.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Rust review

Review Rust code against the same rules the `rust-best-practices` skill uses for writing
it, and report what to change. The output is a review, not a rewrite: the reader decides
what to fix. Only rewrite code when the user asks for that.

## 1. Decide the scope

- **What to read.** Review exactly what the user pointed at: a file, a module, a crate,
  or a diff. For a diff, review the changed lines and anything they break, not the whole
  file.
- **Library or application.** Check for a `lib.rs`, `pub` items used by other crates, or
  a published `Cargo.toml`. Library code is held to the API-design rules strictly.
  Application code gets the simplicity rules instead: concrete types, `anyhow`-style
  errors, and no speculative generality. Say which you assumed at the top of the report.
- **The edition and MSRV**, from `Cargo.toml`, so you don't recommend features the
  project can't use.
- **Frameworks.** If the crate depends on `bevy` or `bevy_ecs`, read the Bevy digest
  (`bevy.md`) in the `rust-best-practices` skill's references first. It lists the Bevy
  conventions to leave alone (by-value system parameters, the prelude, plain-data
  components) and the ECS bugs to look for.

## 2. Run the tools first, if you can

If a Rust toolchain is available, run these from the crate root and fold the results into
the report. They catch the mechanical issues, which leaves you free for design.

```bash
cargo fmt --check
cargo clippy --all-targets --all-features -- -W clippy::pedantic
cargo test
```

Don't paste raw clippy output. Group repeated warnings into one finding, and skip pedantic
lints that don't matter for this code. If the tools aren't available, say so in the report
and review by reading.

## 3. What to look for, in priority order

Work through these in order. The first two categories are where real bugs live.

**Correctness and soundness**

The rest: https://github.com/morganlinton/BeautifulRust/blob/HEAD/skills/rust-review/SKILL.md