M02 Resource
Choose the right Rust smart pointer and ownership pattern before you leak memory or fight borrow-checker surprises.
Overview
m02-resource is an agent skill most often used in Build (also Ship when debugging ownership) that guides Rust smart-pointer and RAII choices from ownership, threading, and cycle constraints.
Install
npx skills add https://github.com/zhanghandong/rust-skills --skill m02-resourceWhat is this skill?
- Maps errors (heap need, Rc leaks, RefCell panics) to design questions instead of copy-paste fixes
- Three-step thinking prompt: ownership model, thread context, and cycle detection
- Explicit Rc vs Arc and single-thread vs multi-thread guidance with Mutex/RwLock pointers
- RAII, Drop, and when stack allocation is enough before reaching for Box
- Trigger coverage for Box, Arc, Weak, RefCell, Cell, and reference-counting tradeoffs
Adoption & trust: 744 installs on skills.sh; 1.2k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You know you need heap or shared ownership in Rust but keep guessing Box versus Rc versus Arc and paying for leaks, cycles, or RefCell panics.
Who is it for?
Solo builders writing non-trivial Rust who want a repeatable decision frame for pointers and shared state.
Skip if: Pure syntax tutorials or projects with only owned stack values and no shared or heap resources.
When should I use this skill?
CRITICAL: Use for smart pointers and resource management when triggers include Box, Rc, Arc, Weak, RefCell, Cell, RAII, Drop, or Arc vs Rc questions.
What do I get? / Deliverables
You pick a coherent ownership model with the right pointer types and cycle strategy before implementing or refactoring the resource.
- Chosen smart-pointer strategy with threading and cycle notes
- Refactor or implementation plan aligned to RAII and Drop
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Resource and smart-pointer decisions are made continuously while implementing Rust backends, CLIs, and agents. Backend and systems Rust code is where Box, Rc, Arc, RefCell, and cycle-breaking Weak references show up most often.
Where it fits
Model a shared in-memory graph and decide Rc plus Weak versus Arc before coding the API layer.
Wrap a C API return type and choose Box versus owned buffers for FFI boundaries.
Review a PR that introduced Arc everywhere and trim threading assumptions to Rc where safe.
Diagnose a RefCell panic in production logs and decide if runtime interior mutability is still the right design.
How it compares
Use as a design checklist instead of chasing individual borrow-checker errors in isolation.
Common Questions / FAQ
Who is m02-resource for?
Indie and solo developers implementing Rust backends, CLIs, or tools who hit smart-pointer and sharing decisions regularly.
When should I use m02-resource?
During Build when modeling shared graphs or heap data; during Ship when investigating Rc cycles, Arc contention, or RefCell borrow panics.
Is m02-resource safe to install?
Review the Security Audits panel on this Prism page and your repo trust settings before adding any third-party skill package.
SKILL.md
READMESKILL.md - M02 Resource
# 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