Design and review Rust trait APIs, generic bounds, dispatch models, and conversion contracts for clear public interfaces.
SkillScore100Maintained
Automatic
◆Coding pack
Last verified 8/16/2026
What it changes
Passed 23 of 23 test cases with the skill, and 22 of 23 without it.
Without skill96%
With skill100%
Checks it passed that the model alone missed
Recommends keeping the concrete `File` parameter type
1 fixed22 passed either way0 still failing0 broke
Pass-rate lift
+4 pp
Tokens
+12%
Agent turns
0%
Response time
-29%
Model gemini-3.6-flashMeasured 8/16/2026v123 of 23 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
A test case the skill fixed. Same model, same prompt, with and without the skill.
Prompt
I am writing a new local helper function in a Rust module to parse data from a `std::fs::File`. This function is only called from one single location in my private module. Should I make it generic `fn parse<R: Read>(reader: R)` or keep it concrete `fn parse(file: &File)`?
What was checked, without and with the skill
Checked
Without skill
With skill
Recommends keeping the concrete `File` parameter type
Missed
Passed
case-15 · gemini-3.6-flash · 8/16/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md66 lines2 files
Rust Trait API Design
Use this skill to make Rust APIs generic where useful, concrete where simpler,
and object-safe when dynamic dispatch is part of the design. Optimize for the
smallest capability contract that callers and implementors can understand.
Core Workflow
Identify whether the API consumes, borrows, returns, stores, or dispatches
behavior.
Start with concrete types for local code. Generalize only when at least two
callers or implementations need the flexibility.
Use generic bounds for compile-time polymorphism and inlining. Use dyn Trait for heterogeneous values, plugin-like extension points, or runtime
dispatch.
Place bounds at the point that needs them. Prefer where clauses when
bounds are long or involve associated types.
Decide whether a trait is intended for downstream implementation. Seal it,
keep fields private, or use constructors when invariants must not be
implemented externally.
Use standard conversion traits where they match exactly. Do not invent a
custom conversion trait before checking From, TryFrom, AsRef, AsMut,
Borrow, ToOwned, and Cow.
Add compile tests, unit tests, or examples that prove the public API is
callable the way the skill expects future users to call it.
API Design Rules
Accept impl Trait or a named generic for parameters when callers should
pass many concrete types.
Return impl Trait when hiding one concrete return type. Return Box<dyn Trait> when the concrete type varies at runtime.
Prefer associated types when each implementation has one natural related
type. Prefer generic trait parameters when one implementation supports many
target types.
Implement From for infallible conversions and TryFrom for fallible
conversions. Implementing these gives callers Into and TryInto.
Use AsRef for cheap reference-to-reference conversion. Use Borrow only
when borrowed and owned forms have equivalent Eq, Hash, and Ord
behavior.