rust-expert-best-practices-code-review
Rust best practices and code quality guidelines for writing idiomatic, safe, and performant Rust code. This skill should be used when writing, reviewing, or refactoring Rust code. Triggers on tasks involving Rust programming, code review, error handling, type safety, or performance optimization.
Works with
--- name: rust-expert-best-practices-code-review description: Rust best practices and code quality guidelines for writing idiomatic, safe, and performant Rust code. This skill should be used when writing, reviewing, or refactoring Rust code. Triggers on tasks involving Rust programming, code review, error handling, type safety, or performance optimization. license: MIT --- # Rust Expert Best Practices Simple, pragmatic, opinionated. Only what matters for writing production-grade Rust code. ## When to Apply Reference these guidelines when: - Writing Rust code (structs, functions, enums, traits) - Implementing error handling and Result types - Reviewing Rust code for safety or performance issues - Refactoring existing Rust codebases - Designing APIs and public interfaces - Optimizing Rust code for performance or clarity ## Rule Categories by Priority | Priority | Category | Impact | Prefix | |----------|----------|--------|--------| | 1 | Type Safety | CRITICAL | `use-typesafe-`, `use-enum-` | | 2 | Error Handling | CRITICAL-HIGH | `result-`, `avoid-panic` | | 3 | API Design | HIGH | `use-borrowed-`, `prefer-builder-` | | 4 | Code Quality | MEDIUM-HIGH | `use-iterator-`, `prefer-format` | | 5 | Readability | MEDIUM | `use-named-`, `avoid-boolean-` | | 6 | Performance | MEDIUM | `avoid-rc`, `avoid-box` | ## Quick Reference - `use-borrowed-argument-types` - Use &str, &[T], &Path instead of &String, &Vec<T>, &PathBuf - `use-enum-deserialization` - Use exhaustive enum matching for safe deserialization - `use-typesafe-index-wrappers` - Wrap index types to prevent mixing different indices - `result-error-returns` - Use ? operator instead of unwrap/expect in Result functions - `avoid-panic` - Use assert!, Result, or expect based on context instead of panic! - `use-iterator-transforms` - Use iterator methods instead of explicit push loops - `use-copied` - Use .copied() to avoid complex dereferencing patterns - `prefer-format` - Use format! over manual string concatenation - `prefer-builder-pattern-for-complex` - Use builder pattern for functions with 4+ parameters - `use-named-placeholders` - Use named placeholders instead of bare _ in destructuring - `decimal-comparison` - Use .is_sign_negative() instead of comparing to Decimal::ZERO - `calculated-field-as-method` - Implement calculated fields as methods not struct fields - `avoid-rc` - Avoid unnecessary Rc<T> when simpler ownership patterns work - `avoid-box` - Don't use Box<T> for concrete types without legitimate reason - `avoid-boolean-params` - Replace boolean parameters with enums or structs - `match-statements-handle-all-cases` - Explicitly handle all enum variants without catch-all patterns ## How to Use Read individual rule files for detailed explanations and code examples: ``` rules/use-borrowed-argument-types.md rules/use-enum-deserialization.md rules/use-typesafe-index-wrappers.md rules/result-error-returns.md rules/avoid-panic.md rules/use-iterator-transforms.md rules/use-copied.md rules/prefer-format.md rules/prefer-builder-pattern-for-complex.md rules/use-named-placeholders.md rules/decimal-comparison.md rules/calculated-field-as-method.md rules/avoid-rc.md rules/avoid-box.md rules/avoid-boolean-params.md rules/match-statements-handle-all-cases.md ``` Each rule file contains: - Brief explanation of why it matters - When to use and when not to use the pattern - Implementation requirements - BAD code examples with explanation - GOOD code examples with explanation - Additional context and best practices
More Code Review skills
pr-to-video
heygen-com/hyperframes
Turn a GitHub pull request (a PR URL, owner/repo#N, or 'this PR' in a checked-out repo) into a code-change explainer video — changelog, feature reveal, fix, or refactor walkthrough built from the diff, commits, and files: the input is a code change, not a website. Not a product promo (/product-launch-video) or a no-PR topic explainer (/faceless-explainer). Unclear → /hyperframes.
receiving-code-review
obra/superpowers
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
public-relations
coreyhaines31/marketingskills
When the user wants help with public relations, earned media, press coverage, journalist outreach, or media strategy (not pull requests). Also use when the user mentions 'PR,' 'public relations,' 'press,' 'press release,' 'press coverage,' 'media outreach,' 'pitch a journalist,' 'get featured,' 'media list,' 'media kit,' 'press kit,' 'newsjacking,' 'news hijack,' 'HARO,' 'Qwoted,' 'Featured,' 'Help A Reporter,' 'reporter request,' 'tech press,' 'TechCrunch,' 'earned media,' 'thought leadership placement,' 'op-ed,' 'guest article,' 'press contacts,' 'podcast prep,' 'going on a podcast,' 'podcast guest,' 'prep me for this podcast,' or 'how do I get press.' Use this for earned media work — finding journalists, pitching stories, newsjacking, prepping podcast appearances, and responding to press requests. For startup/SaaS/AI directory submissions, see directory-submissions. For product launches, see launch. For social-media engagement, see social. For cold-email outreach to prospects, see cold-email.

