PaperclipOrg
Claude Agent Skill · by Zhanghandong

M02 Resource

m02-resource guides developers through selecting appropriate smart pointers and resource management patterns in Rust by asking design questions rather than pres

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

How M02 Resource fits into a Paperclip company.

M02 Resource 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.md159 lines
Expand
---name: m02-resourcedescription: "CRITICAL: Use for smart pointers and resource management. Triggers: Box, Rc, Arc, Weak, RefCell, Cell, smart pointer, heap allocation, reference counting, RAII, Drop, should I use Box or Rc, when to use Arc vs Rc, 智能指针, 引用计数, 堆分配"user-invocable: false--- # Resource Management > **Layer 1: Language Mechanics** ## Core Question **What ownership pattern does this resource need?** Before choosing a smart pointer, understand:- Is ownership single or shared?- Is access single-threaded or multi-threaded?- Are there potential cycles? --- ## Error → Design Question | Error | Don't Just Say | Ask Instead ||-------|----------------|-------------|| "Need heap allocation" | "Use Box" | Why can't this be on stack? || Rc memory leak | "Use Weak" | Is the cycle necessary in design? || RefCell panic | "Use try_borrow" | Is runtime check the right approach? || Arc overhead complaint | "Accept it" | Is multi-thread access actually needed? | --- ## Thinking Prompt Before choosing a smart pointer: 1. **What's the ownership model?**   - Single owner → Box or owned value   - Shared ownership → Rc/Arc   - Weak reference → Weak 2. **What's the thread context?**   - Single-thread → Rc, Cell, RefCell   - Multi-thread → Arc, Mutex, RwLock 3. **Are there cycles?**   - Yes → One direction must be Weak   - No → Regular Rc/Arc is fine --- ## Trace Up ↑ When pointer choice is unclear, trace to design: ```"Should I use Arc or Rc?"    ↑ Ask: Is this data shared across threads?    ↑ Check: m07-concurrency (thread model)    ↑ Check: domain-* (performance constraints)``` | Situation | Trace To | Question ||-----------|----------|----------|| Rc vs Arc confusion | m07-concurrency | What's the concurrency model? || RefCell panics | m03-mutability | Is interior mutability right here? || Memory leaks | m12-lifecycle | Where should cleanup happen? | --- ## Trace Down ↓ From design to implementation: ```"Need single-owner heap data"    ↓ Use: Box<T> "Need shared immutable data (single-thread)"    ↓ Use: Rc<T> "Need shared immutable data (multi-thread)"    ↓ Use: Arc<T> "Need to break reference cycle"    ↓ Use: Weak<T> "Need shared mutable data"    ↓ Single-thread: Rc<RefCell<T>>    ↓ Multi-thread: Arc<Mutex<T>> or Arc<RwLock<T>>``` --- ## Quick Reference | Type | Ownership | Thread-Safe | Use When ||------|-----------|-------------|----------|| `Box<T>` | Single | Yes | Heap allocation, recursive types || `Rc<T>` | Shared | No | Single-thread shared ownership || `Arc<T>` | Shared | Yes | Multi-thread shared ownership || `Weak<T>` | Weak ref | Same as Rc/Arc | Break reference cycles || `Cell<T>` | Single | No | Interior mutability (Copy types) || `RefCell<T>` | Single | No | Interior mutability (runtime check) | ## Decision Flowchart ```Need heap allocation?├─ Yes → Single owner?│        ├─ Yes → Box<T>│        └─ No → Multi-thread?│                ├─ Yes → Arc<T>│                └─ No → Rc<T>└─ No → Stack allocation (default) Have reference cycles?├─ Yes → Use Weak for one direction└─ No → Regular Rc/Arc Need interior mutability?├─ Yes → Thread-safe needed?│        ├─ Yes → Mutex<T> or RwLock<T>│        └─ No → T: Copy? → Cell<T> : RefCell<T>└─ No → Use &mut T``` --- ## Common Errors | Problem | Cause | Fix ||---------|-------|-----|| Rc cycle leak | Mutual strong refs | Use Weak for one direction || RefCell panic | Borrow conflict at runtime | Use try_borrow or restructure || Arc overhead | Atomic ops in hot path | Consider Rc if single-threaded || Box unnecessary | Data fits on stack | Remove Box | --- ## Anti-Patterns | Anti-Pattern | Why Bad | Better ||--------------|---------|--------|| Arc everywhere | Unnecessary atomic overhead | Use Rc for single-thread || RefCell everywhere | Runtime panics | Design clear ownership || Box for small types | Unnecessary allocation | Stack allocation || Ignore Weak for cycles | Memory leaks | Design parent-child with Weak | --- ## Related Skills | When | See ||------|-----|| Ownership errors | m01-ownership || Interior mutability details | m03-mutability || Multi-thread context | m07-concurrency || Resource lifecycle | m12-lifecycle |