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
- XGENT-ai/skillstheir own version, first seen Nov 8, 2026
- po4yka/rust-skillstheir own version, first seen Nov 8, 2026
- inference-gateway/skillstheir own version, first seen Nov 5, 2026
- kabudu/engineering-agent-skillstheir own version, first seen Nov 1, 2026
- fedemelo/agent-configtheir own version, first seen Nov 1, 2026
- tuan3w/herdr-mobiletheir own version, first seen Nov 1, 2026
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.
weedmoSkillrust-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
kingsidharthSkillpython-review
Also in 3 projects that use this
MicrosoftSkillrust-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
GoogleSkilltdd
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
Other versions13 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 13
- cloudflare/workerd★ 9.1ksame name
- fallow-rs/fallow★ 5.3ksame name
- morganlinton/BeautifulRust★ 1.8ksame name
- tuan3w/herdr-mobile★ 29same name
- po4yka/rust-skills★ 5same name
- fedemelo/agent-config★ 4same name
- jscott3201/yet-more-skills★ 4same name
- inference-gateway/skills★ 3same name
- kabudu/engineering-agent-skills★ 3same name
- BenSchZA/skills★ 1same name
3 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository24 other files it gives its agents.
- api-designSkill
- brainstormingSkill
- councilSkill
- dispatching-parallel-agentsSkill
- document-toolkitSkill
- executing-plansSkill
- gui-input-automationSkill
- humanizeSkill
- hyprland-controlSkill
- incremental-implementationSkill
- issue-to-prSkill
- litreviewSkill
- mcp-builderSkill
- screen-captureSkill
- session-handoffSkill
- shadcn-auditSkill
- spec-to-issuesSkill
- subagent-driven-developmentSkill
- teachSkill
- unslopSkill
- using-git-worktreesSkill
- visual-computer-use-loopSkill
- writing-flowSkill
- writing-plansSkill
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
- Very specific: line 21
If cargo-audit / cargo-deny are installed, run them for advisories: cargo audit.
- Very specific: line 26
Unsafe: Every unsafe block needs a comment stating the invariant that makes it sound, and a reason a safe alternative won't do.
- Very specific: line 32
Prefer ?, ok_or, get, checked_*.
- Very specific: line 48
Async (tokio): No blocking calls (std::fs, std::thread::sleep, heavy CPU) inside async tasks — use the async equivalents or spawn_blocking.
“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.
Files
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 # warningsIf 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.
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
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.

