M15 Anti Pattern
Run Rust-specific code review that spots idiomatic mistakes (clone spam, unwrap in prod, ownership fights) and maps each smell to a better pattern.
Overview
m15-anti-pattern is an agent skill most often used in Ship (also Build) that reviews Rust for anti-patterns and redirects fixes toward idiomatic ownership and error-handling design.
Install
npx skills add https://github.com/zhanghandong/rust-skills --skill m15-anti-patternWhat is this skill?
- Maps eight common Rust anti-patterns (clone everywhere, unwrap in production, Rc misuse, unsafe shortcuts, Deref OOP, gi
- Layer-2 design lens: symptom vs cause, fight vs flow with the borrow checker
- Thinking prompt workflow for suspicious code during review
- Keyword triggers for borrow-checker fights, clone-everywhere, and refactor decisions
- Bilingual discovery keywords (EN + 反模式 / 代码异味)
- 8 anti-pattern rows in the core Anti-Pattern → Better Pattern table
- Layer 2 design-choices framing with a 4-step thinking prompt
Adoption & trust: 5.5k installs on skills.sh; 1.2k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You keep patching Rust with clone and unwrap because borrow errors are painful, and you are not sure if the code is hiding a deeper design mistake.
Who is it for?
Solo builders doing Rust code review or pre-merge self-review who want structured anti-pattern callouts tied to ownership and API design.
Skip if: Teams that need automated lint-only fixes with zero design discussion, or non-Rust codebases where the borrow-checker table does not apply.
When should I use this skill?
Reviewing code for anti-patterns; keywords include anti-pattern, code smell, clone everywhere, unwrap in production, fighting borrow checker, idiomatic way.
What do I get? / Deliverables
Review comments classify each smell against known anti-patterns and point to concrete idiomatic alternatives instead of more defensive clones.
- Anti-pattern callouts tied to better patterns
- Design-focused review notes (symptom vs cause)
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Anti-pattern review belongs on the ship shelf because it is invoked when validating Rust before release, even though you can also use it while still writing code in build. Review is the canonical subphase: the skill’s core question is whether a pattern hides a design problem during code review, not greenfield scaffolding.
Where it fits
While implementing a Rust API handler, ask whether repeated clone() is masking an ownership design issue.
Before merge, run a structured pass on match arms and error handling instead of ad-hoc nitpicks.
When production panics trace to unwrap, use the table to plan a safer error path in the next patch.
How it compares
Use as a design-oriented Rust review rubric, not as a substitute for clippy lints or cargo test.
Common Questions / FAQ
Who is m15-anti-pattern for?
Indie and solo developers shipping Rust who want their agent to flag common mistakes and suggest idiomatic refactors during review.
When should I use m15-anti-pattern?
During ship review before merging, while refactoring borrow-checker workarounds in build backend work, or when asking if clone-everywhere or unwrap-in-production is an anti-pattern.
Is m15-anti-pattern safe to install?
It is procedural review guidance with no network or shell requirements in the skill itself; confirm repo trust and check the Security Audits panel on this Prism page before adding any skill pack.
SKILL.md
READMESKILL.md - M15 Anti Pattern
# 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 _ =` | --- ## Thinking Prompt When seeing suspicious code: 1. **Is this symptom or cause?** - Clone to avoid borrow? → Ownership design issue - Unwrap "because it won't fail"? → Unhandled case 2. **What would idiomatic code look like?** - References instead of clones - Iterators instead of index loops - Pattern matching instead of flags 3. **Does this fight Rust?** - Fighting borrow checker → restructure - Excessive unsafe → find safe pattern --- ## Trace Up ↑ To design understanding: ``` "Why does my code have so many clones?" ↑ Ask: Is the ownership model correct? ↑ Check: m09-domain (data flow design) ↑ Check: m01-ownership (reference patterns) ``` | Anti-Pattern | Trace To | Question | |--------------|----------|----------| | Clone everywhere | m01-ownership | Who should own this data? | | Unwrap everywhere | m06-error-handling | What's the error strategy? | | Rc everywhere | m09-domain | Is ownership clear? | | Fighting lifetimes | m09-domain | Should data structure change? | --- ## Trace Down ↓ To implementation (Layer 1): ``` "Replace clone with proper ownership" ↓ m01-ownership: Reference patterns ↓ m02-resource: Smart pointer if needed "Replace unwrap with proper handling" ↓ m06-error-handling: ? operator ↓ m06-error-handling: expect with message ``` --- ## Top 5 Beginner Mistakes | Rank | Mistake | Fix | |------|---------|-----| | 1 | Clone to escape borrow checker | Use references | | 2 | Unwrap in production | Propagate with `?` | | 3 | String for everything | Use `&str` | | 4 | Index loops | Use iterators | | 5 | Fighting lifetimes | Restructure to own data | ## Code Smell → Refactoring | Smell | Indicates | Refactoring | |-------|-----------|-------------| | Many `.clone()` | Ownership unclear | Clarify data flow | | Many `.unwrap()` | Error handling missing | Add proper handling | | Many `pub` fields | Encapsulation broken | Private + accessors | | Deep nesting | Complex logic | Extract methods | | Long functions | Multiple responsibilities | Split | | Giant enums | Missing abstraction | Trait + types | --- ## Common Error Patterns | Error | Anti-Pattern Cause | Fix | |-------|-------------------|-----| | E0382 use after move | Cloning vs ownership | Proper references | | Panic in production | Unwrap everywhere | ?, matching | | Slow performance | String for all text | &str, Cow | | Borrow checker fights | Wrong structure | Restructure | | Memory bloat | Rc/Arc everywhere | Simple ownership | --- ## Deprecated → Better | Deprecated | Better | |------------|--------| | Index-based loops | `.iter()`, `.enumerate()` | | `collect::<Vec<_>>()`