agentleFS
hdprajwalhdprajwal/agent-skills/skills/rust-review/SKILL.md

rust-review

Skill1 starsChanged 5 months agoMITView on GitHub

Review Rust code for correctness, safety, idioms, and performance — run clippy/fmt, audit unsafe and unwrap, check ownership/borrowing and error handling, spot async pitfalls, and confirm tests. Use when reviewing or hardening Rust before merge, or when asked to make Rust more idiomatic. Runs the toolchain first, then reads for what tools can't catch.

13 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use rust-port, python-review and 2 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • weedmoSkill

    rust-port

    Port an existing codebase or hot path to Rust from any language (Python, C, C++, Go, JS/TS, Java/Kotlin, C#) with an oracle-first workflow: profile to pick targets, freeze equivalence tests before porting, design the FFI boundary, then gate on differential tests and 1-thread vs N-thread release benchmarks. Use when the user asks to rewrite, port, migrate, or speed up code in Rust (PyO3/maturin, napi-rs, jni-rs, cxx, c2rust), or to review such a port.

    Also in 6 projects that use this

  • kingsidharthSkill

    python-review

    Also in 3 projects that use this

  • MicrosoftSkill

    rust-best-practices

    Guide for writing idiomatic Rust code based on Apollo GraphQL's best practices handbook. Use this skill when: (1) writing new Rust code or functions, (2) reviewing or refactoring existing Rust code, (3) deciding between borrowing vs cloning or ownership patterns, (4) implementing error handling with Result types, (5) optimizing Rust code for performance, (6) writing tests or documentation for Rust projects.

    Also in 4 projects that use this

  • GoogleSkill

    tdd

    Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

4 rules. 0 are common, 0 are distinctive, and 4 are very specific to this project.

  • 0

    Common

    Most of the 12 edited versions we read keep these.

  • 0

    Distinctive

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    If cargo-audit / cargo-deny are installed, run them for advisories: cargo audit.

    line 21
  2. Very specific:

    Unsafe: Every unsafe block needs a comment stating the invariant that makes it sound, and a reason a safe alternative won't do.

    line 26
  3. Very specific:

    Prefer ?, ok_or, get, checked_*.

    line 32
  4. Very specific:

    Async (tokio): No blocking calls (std::fs, std::thread::sleep, heavy CPU) inside async tasks — use the async equivalents or spawn_blocking.

    line 48

“Common” is measured: kept by at least 6 in 10 of the 12 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Rust Review

Let the toolchain do the mechanical pass first, then read for the things it can't see. Don't hand-review what clippy already flags.

1. Run the toolchain

cargo fmt --check                 # formatting
cargo clippy --all-targets --all-features -- -D warnings   # lints as errors
cargo test                        # tests pass
cargo build --release 2>&1 | tail # warnings

If cargo-audit / cargo-deny are installed, run them for advisories: cargo audit. Fix or justify every clippy finding — don't #[allow] silently.

2. Read for what clippy misses

Unsafe. Every unsafe block needs a comment stating the invariant that makes it sound, and a reason a safe alternative won't do. Unjustified unsafe is the highest-priority finding.

Panics in library code. unwrap() / expect() / panic! / indexing v[i] / integer division — fine in tests and main, suspect in library paths. Prefer ?, ok_or, get, checked_*. Flag each one: can this input make it panic?

Error handling. Libraries: typed errors (thiserror). Applications: anyhow/eyre with context (.with_context(...)). Errors should say what failed and why. No Result<_, String> in real code.

Ownership & borrowing. Needless .clone() to dodge the borrow checker; String where &str would do; Vec<T> args where &[T] works; returning owned data that could be borrowed. APIs should take the least-owning type that works.

Idioms. Iterator chains over manual index loops; if let / let else / matches! over verbose matches; impl Trait where it reads cleaner; derive (Debug, Clone, PartialEq) rather than hand-writing; From/TryFrom for conversions. Newtypes over bare primitives for domain types.

Async (tokio). No blocking calls (std::fs, std::thread::sleep, heavy CPU) inside async tasks — use the async equivalents or spawn_blocking. Watch for holding a std/parking_lot lock across .await (deadlock risk); don't .await while holding a Mutex guard. Check that spawned tasks are awaited or intentionally detached, and that cancellation is handled.

Concurrency. Arc<Mutex<…>> that could be a channel or RwLock; data shared without Send/Sync thought-through.

3. Tests

  • Meaningful coverage of behavior and failure paths, not just the happy path.
  • #[should_panic] / Result-returning tests where apt.
  • Property tests (proptest) for parsers/encoders.
  • Doc examples (cargo test --doc) compile and run.

Severity

  • Blocker: unjustified unsafe, a reachable panic on user input, a .await-across-lock deadlock, UB.
  • Important: missing error context, needless clones in hot paths, blocking in async, missing tests on a failure path.
  • Minor: non-idiomatic but correct; naming; style clippy didn't catch.

Report findings as file:line + the concrete fix. Only flag what's worth the author's time.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.