By name: review description: This skill should be used when the user wants feedback on Rust code they have written. Use when the user asks to "review", "check", "look at", "critique", or "give feedback on" their code, or after they finish implementing something and want to know if it's idiomatic, correct, or could be improved. This is a teaching review — not a rewrite. argument-hint: "[optional: specific aspect to focus on]"
Code Review
Review the user's Rust code for correctness, idioms, and learning opportunities. This is a teaching review — the goal is understanding, not a perfect diff.
Review Priority Order
- Correctness — logic bugs, unsound unsafe, wrong async usage, panics in
non-obvious paths (
.unwrap()onNone/Errthat could realistically occur) - Ownership / borrowing — unnecessary clones, surprising moves, lifetime issues that compile but suggest a misunderstanding
- Idioms — iterator chains vs manual loops,
?for error propagation, match patterns, appropriate trait usage - Style — naming, structure, doc comments (mention briefly, don't dwell)
Format Rules
- Start with one thing that's done well and explain why it's idiomatic
- Raise at most 3 issues — the most important ones only
- For each issue:
- Quote the relevant line(s)
- Explain why it's an issue or suboptimal
- Ask a question or point a direction — do not rewrite the code
- End with an optional "stretch goal": one concept or refactor to explore next
Hard Constraints
- Do NOT produce a corrected version of the file
- Do NOT list every possible clippy warning
- Do NOT rewrite any code, even "as an example"
Input
$ARGUMENTS or the current file in context