M15 Anti Pattern

Catches you when you're fighting Rust instead of working with it. Reviews code for the classic mistakes: cloning everywhere to escape the borrow checker, unwrapping in production code, using String when you need &str, index loops instead of iterators. The pattern tables are solid references, especially the trace ups that connect surface symptoms like "too many clones" back to ownership design issues. Sits at Layer 2 in the skill system, so it bridges the gap between seeing suspicious code and understanding why it's wrong. The checklist is honest about what matters in code review. Most useful when you're reviewing PR feedback and want to understand whether you're patching symptoms or fixing the actual problem.

skills.sh installs: 9.3K
GitHub stars: 1.6K
last updated: Aug 21, 2026

View on GitHub

Install

$ npx -y skills add actionbook/rust-skills --skill m15-anti-pattern --agent claude-code

Installs into .claude/skills of the current project.

Files

Anti-Patterns

Layer 2: Design Choices

Core Question

Is this pattern hiding a design problem?

When reviewing code:

Is this solving the symptom or the cause?
Is there a more idiomatic approach?
Does this fight or flow with Rust?

Anti-Pattern → Better Pattern

Anti-Pattern	Why Bad	Better
`.clone()` everywhere	Hides ownership issues	Proper references or ownership
`.unwrap()` in production	Runtime panics	`?`, `expect`, or handling
`Rc` when single owner	Unnecessary overhead	Simple ownership
`unsafe` for convenience	UB risk	Find safe pattern
OOP via `Deref`	Misleading API	Composition, traits
Giant match arms	Unmaintainable	Extract to methods
`String` everywhere	Allocation waste	`&str`, `Cow<str>`
Ignoring `#[must_use]`	Lost errors	Handle or `let _ =`