m15-anti-pattern_skill

This skill helps you identify and replace anti-patterns in Rust code, improving idiomatic design and reliability during reviews.
  • Shell

565

GitHub Stars

1

Bundled Files

2 months ago

Catalog Refreshed

4 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill zhanghandong/rust-skills --skill m15-anti-pattern

  • SKILL.md4.7 KB

Overview

This skill helps reviewers identify common Rust anti-patterns and practical refactorings. It focuses on design-level issues that mask underlying problems, like excessive cloning, unwraps in production, and inappropriate smart pointer use. Use it to turn symptoms into corrective design changes and more idiomatic Rust code.

How this skill works

The skill inspects code for recurring smells: clone-everywhere, unwraps, unnecessary Rc/Arc, oversized functions/enums, index loops, and unsafe shortcuts. For each finding it asks whether the code is treating a symptom instead of the root cause and points to safer, idiomatic alternatives. It traces suggestions upward to ownership and domain design and downward to concrete implementation fixes.

When to use it

  • During code review to flag design-level smells and risky shortcuts
  • When diagnosing performance or correctness issues related to ownership and lifetime handling
  • Before merging library code to ensure no unwraps or ignored #[must_use] warnings
  • When mentoring juniors to explain why a pattern is fragile or non-idiomatic
  • When planning a refactor to reduce cloning, panics, or unnecessary indirection

Best practices

  • Prefer references or ownership redesign over liberal .clone() usage
  • Avoid unwrap() in production; propagate errors with ? or use expect() with context
  • Replace index loops with iterators and use &str or Cow<str> to avoid needless allocations
  • Limit public fields; encapsulate invariants and provide accessors
  • Keep functions small and extract large match arms into methods or trait implementations

Example use cases

  • Find and remove unnecessary .clone() calls and propose reference-based alternatives
  • Replace pervasive unwrap() usage with a consistent error-handling strategy
  • Detect Rc/Arc where single ownership suffices and suggest ownership simplification
  • Refactor long functions and giant enums into clearer abstractions and traits
  • Advise safe alternatives to unsafe blocks and point to standard library types like Cell/RefCell

FAQ

No. Cloning is valid when ownership copying is intended or cheap. The question is whether clones are masking an ownership design issue; prefer references when appropriate.

When is unwrap acceptable?

unwrap is acceptable in tests, prototypes, or binary main logic where a clear panic is preferable; avoid it in libraries and production paths—use ? or expect with helpful messages instead.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational
m15-anti-pattern skill by zhanghandong/rust-skills | VeilStrat