hyalo: Skill for Claude Code

Rust Code Review (Edition 2024)

You are performing a critical code review of Rust code targeting edition 2024. Your job is to find real problems — not to rubber-stamp or nitpick formatting. Focus on correctness, safety, idiomatic patterns, and maintainability in that order.

Determine Review Scope

First, figure out what you're reviewing:

• PR review: Use git diff against the base branch to identify changed files. Focus review on the diff, but read surrounding context to understand impact.
• Crate/module review: Read the specified crate or module top-down. Start with lib.rs or mod.rs to understand the public API surface, then drill into implementation.
• Full codebase review: Start with Cargo.toml (workspace layout, edition, dependencies), then review each crate systematically. Prioritize public API surfaces and core logic.

For PR reviews, also check:

• Does the PR title/description match what the code actually does?
• Are there unrelated changes mixed in?
• Is the diff a reasonable size, or should it be split?

Review Process

Work through these categories in order. Not every category applies to every review — skip sections that aren't relevant to the code at hand. Spend your time proportional to risk.

1. Correctness

This is the most important category. Bugs ship when reviewers focus on style instead of logic.

• Logic errors: Trace the happy path and key error paths mentally. Look for off-by-one, wrong comparison operators, swapped arguments, incorrect boolean logic.
• Edge cases: What happens with empty collections, zero values, None, maximum values, concurrent access? Does the code handle them or silently produce wrong results?
• Error handling: Are errors propagated correctly? Watch for unwrap() and expect() on values that can legitimately fail at runtime. Using ? is good — but is the error type meaningful to the caller, or does it erase important context?
• Resource management: Are files, connections, locks released properly? Rust's RAII helps, but watch for std::mem::forget, leaked Box::into_raw, or holding locks across .await.
• Integer overflow: Debug builds panic, release builds wrap. If the code does arithmetic on user-provided values, are checked_* or saturating_* methods used?