Enforces the official Rust API Guidelines (https://rust-lang.github.io/api-guidelines/) when writing, reviewing, or refactoring Rust library code. Use this skill whenever you are writing new Rust structs, enums, traits, functions, or modules that form a public API — including when designing error types, implementing conversions, naming methods, adding documentation, creating macros, or structuring crate features. Also use it when reviewing existing Rust code for API quality, idiomatic patterns, or crate publishing readiness. Trigger on any Rust library design task, even if the user doesn't explicitly mention "API guidelines."
Enforces the official Rust API Guidelines (https://rust-lang.github.io/api-guidelines/) when writing, reviewing, or refactoring Rust library code. Use this skill whenever you are writing new Rust structs, enums, traits, functions, or modules that form a public API — including when designing error types, implementing conversions, naming methods, adding documentation, creating macros, or structuring crate features. Also use it when reviewing existing Rust code for API quality, idiomatic patterns, or crate publishing readiness. Trigger on any Rust library design task, even if the user doesn't explicitly mention "API guidelines."
Rust API Guidelines
The official Rust API Guidelines capture the Rust library team's consensus on idiomatic, interoperable crate design. They cover naming, trait implementations, documentation, type safety, macros, and more. Use the checklist below when writing, reviewing, or publishing Rust library code.
Public dependencies of a stable crate are stable ([C-STABLE])
Crate and its dependencies have a permissive license ([C-PERMISSIVE])
How to Use
When writing or reviewing Rust library code, walk through the checklist above. Each section
heading links to a reference file with full rationale, examples, and edge cases -- read those
when you need deeper context. The most commonly missed items are: missing Debug impls, missing
common trait impls (Clone, Default), get_ prefixes on getters, unwrap() in doc
examples, missing # Errors/# Panics sections, and implementing Into instead of From.
When preparing to publish, verify Cargo.toml metadata, licensing, and stable dependencies.
Reviewing Existing Code
When reviewing existing code for conformance to these guidelines:
Only report violations. Do not mention guidelines that the code already follows. The user
only needs to know what to fix.
Format each violation as follows. Use blank lines around each heading for readability:
Violation:
A brief one-or-two-sentence explanation of what the guideline requires and why the code
violates it. Do not repeat the full guideline text.
path/to/file.rs:42: TypeOrFunction — what it is now → what it should be
path/to/file.rs:87: AnotherType — what it is now → what it should be
Include line numbers so users can click to jump to the location in their IDE.
After listing all violations, show a summary table like:
Guideline
Severity
Count
Missing Debug impl
🔴 High
3
Getter naming
🟡 Medium
2
Rank rows from most severe to least severe.
Severity levels: 🔴 High (breaks interoperability, safety, or correctness), 🟡 Medium
(hurts usability or idiomatic style), 🟢 Low (cosmetic or minor convention).
