M02 Resource
Choose the right Rust smart pointer and ownership pattern (Box, Rc, Arc, Weak, RefCell, Cell) before heap allocation or shared-state designs bite you.
Overview
m02-resource is an agent skill most often used in Build (also Ship review, Operate debugging) that guides Rust smart-pointer and RAII choices from ownership and threading requirements.
Install
npx skills add https://github.com/actionbook/rust-skills --skill m02-resourceWhat is this skill?
- Layer 1 language-mechanics guide framed around one core question: what ownership pattern does this resource need?
- Error-to-design table maps Box, Rc, RefCell panic, and Arc overhead to design questions—not one-line fixes
- Thinking prompt covers ownership model, thread context (single vs multi), and cycle risk with Weak
- Explicit triggers: Box, Rc, Arc, Weak, RefCell, Cell, RAII, Drop, heap allocation
- Traces ambiguous Arc-vs-Rc questions upward to actual threading and sharing requirements
- Layer 1: Language Mechanics framing
- Error-to-design table with four common pointer failure modes
Adoption & trust: 960 installs on skills.sh; 1.2k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are unsure whether to use Box, Rc, or Arc—or you hit RefCell panics and suspected Rc leaks—without a clear ownership model for the resource.
Who is it for?
Solo Rust builders implementing backends or CLIs who want Socratic ownership guidance instead of generic “just use Arc” answers.
Skip if: Greenfield Rust learners who have not read The Book’s ownership chapter yet, or pure frontend WASM-only tasks with no shared-state design.
When should I use this skill?
CRITICAL: smart pointers and resource management—Box, Rc, Arc, Weak, RefCell, Cell, RAII, Drop, heap allocation, reference counting.
What do I get? / Deliverables
You leave with a justified smart-pointer strategy aligned to single vs shared ownership, thread context, and cycle breaking with Weak when needed.
- Documented ownership pattern recommendation
- Design questions resolved before pointer choice
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Smart-pointer decisions surface most often while implementing Rust services, CLIs, and systems code—the canonical Build backend shelf. Backend captures ownership-heavy Rust modules where Arc/Mutex graphs and heap layout decisions affect API and service structure.
Where it fits
Pick Arc<Mutex<_>> vs Rc<RefCell<_>> before wiring a shared config graph in a Tokio service.
Review a PR that introduced Rc cycles between parent and child nodes and decide where Weak must break the loop.
Diagnose a RefCell panic in a background task and reconsider whether runtime borrow checks belong in the hot path.
How it compares
Rust ownership design coaching—not a cargo-generate scaffold or a security audit skill.
Common Questions / FAQ
Who is m02-resource for?
Indie and small-team Rust developers wiring heap allocation, shared state, or interior mutability who need disciplined pointer selection.
When should I use m02-resource?
Use it during Build backend work when choosing Box vs Rc vs Arc; during Ship review when auditing Arc/Mutex hot paths; and during Operate when investigating memory leaks or RefCell borrow panics in production services.
Is m02-resource safe to install?
It is instructional markdown without embedded binaries; still review Security Audits on this Prism page before adding any third-party skill pack to your agent.
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