Use when writing, reviewing, or refactoring Rust code, especially workspace crates, public APIs, error handling, async code, ownership choices, or performance-sensitive paths.
NewMaintained
Automatic
◆Coding pack
Last verified 8/21/2026
What it changes
Passed 9 of 22 test cases with the skill, and 13 of 22 without it.
Without skill60%
With skill40%
Checks it passed that the model alone missed
The test uses `unwrap_err()` to retrieve the error value from the `Result`.
The C library function invocation is wrapped inside an `unsafe { ... }` block.
2 fixed11 passed either way6 still failing3 broke
Pass-rate lift
-20 pp
Tokens
+35%
Agent turns
0%
Response time
-22%
Model gemini-3.6-flashMeasured 8/21/2026v113 of 22 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 2 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 2
Prompt
I created a validated struct 'PortNumber(u16)' where valid ports must be between 1024 and 65535. How should a unit test be written to verify that passing port '80' returns an error?
What was checked, without and with the skill
Checked
Without skill
With skill
The test calls `PortNumber::new(80)` and asserts that `.is_err()` returns `true`.
Passed
Passed
The test uses `unwrap_err()` to retrieve the error value from the `Result`.
Missed
Passed
case-19 · gemini-3.6-flash · 8/21/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md128 lines2 files
Rust Programming
Use this skill to keep Rust changes idiomatic, maintainable, and easy to verify.
Operating Rules
Read the surrounding module before changing ownership, trait bounds, public types, or async flow.
Prefer the repository's existing crate boundaries and error types over introducing a new abstraction.
Make invalid states unrepresentable with focused types, enums, and constructors where the domain has real invariants.
Return Result for recoverable failures and reserve panic!, unwrap, and expect for tests, impossible states with a clear message, or process-fatal startup validation.
Keep allocations and clones intentional. Borrow first, clone at ownership boundaries, and document non-obvious lifetime or allocation tradeoffs.
Favor explicit control flow over clever chains when error handling, locking, cancellation, or state mutation is involved.
Keep public APIs small, named consistently, and documented enough that callers know ownership, errors, and side effects.
Run cargo fmt, focused cargo test, and cargo clippy --workspace --all-targets when the change warrants it.
Design Checks
Types: Does the type express the domain, or is it a bag of loosely related fields?
Ownership: Can the caller pass a reference? If ownership is needed, is the transfer visible in the API?
Errors: Is each error actionable at the layer that receives it?
Concurrency: Are locks held for the shortest practical scope, and never across awaits unless deliberately required?
Traits: Are trait bounds on the function that needs them instead of leaking through larger structs?
Testing: Do tests cover behavior and edge cases, not only compilation or snapshots?
Best Practice Patterns
Accept Borrowed Inputs
// Avoid: forces callers to allocate or give up ownership.
fn load_config(path: PathBuf) -> Result<Config, ConfigError> {
std::fs::read_to_string(path)?.parse()
}
// Prefer: accepts Path, PathBuf, and path-like wrappers.
fn load_config(path: impl AsRef<std::path::Path>) -> Result<Config, ConfigError> {
std::fs::read_to_string(path)?.parse()
}