PaperclipOrg
Claude Agent Skill · by Zhanghandong

M15 Anti Pattern

The m15-anti-pattern skill helps developers identify and refactor common code anti-patterns during code reviews, focusing on Rust-specific issues like excessive

Install
Terminal · npx
$npx skills add https://github.com/zhanghandong/rust-skills --skill m15-anti-pattern
Works with Paperclip

How M15 Anti Pattern fits into a Paperclip company.

M15 Anti Pattern drops into any Paperclip agent that handles this kind of work. Assign it to a specialist inside a pre-configured PaperclipOrg company and the skill becomes available on every heartbeat — no prompt engineering, no tool wiring.

S
SaaS FactoryPaired

Pre-configured AI company — 18 agents, 18 skills, one-time purchase.

$27$59
Explore pack
Source file
SKILL.md160 lines
Expand
---name: m15-anti-patterndescription: "Use when reviewing code for anti-patterns. Keywords: anti-pattern, common mistake, pitfall, code smell, bad practice, code review, is this an anti-pattern, better way to do this, common mistake to avoid, why is this bad, idiomatic way, beginner mistake, fighting borrow checker, clone everywhere, unwrap in production, should I refactor, 反模式, 常见错误, 代码异味, 最佳实践, 地道写法"user-invocable: false--- # 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<_>>()` then iterate | Chain iterators || Manual unsafe cell | `Cell`, `RefCell` || `mem::transmute` for casts | `as` or `TryFrom` || Custom linked list | `Vec`, `VecDeque` || `lazy_static!` | `std::sync::OnceLock` | --- ## Quick Review Checklist - [ ] No `.clone()` without justification- [ ] No `.unwrap()` in library code- [ ] No `pub` fields with invariants- [ ] No index loops when iterator works- [ ] No `String` where `&str` suffices- [ ] No ignored `#[must_use]` warnings- [ ] No `unsafe` without SAFETY comment- [ ] No giant functions (>50 lines) --- ## Related Skills | When | See ||------|-----|| Ownership patterns | m01-ownership || Error handling | m06-error-handling || Mental models | m14-mental-model || Performance | m10-performance |