M02 Resource
- 795 installs
- 1.3k repo stars
- Updated May 24, 2026
- zhanghandong/rust-skills
This is a copy of m02-resource by actionbook - installs and ranking accrue to the original listing.
m02-resource is a Rust agent skill that guides smart-pointer and resource-management decisions for developers who need to choose Box, Rc, Arc, RefCell, or Cell before writing heap-allocated or shared-state code.
About
m02-resource is a Rust language-mechanics skill from zhanghandong/rust-skills that helps developers choose the right ownership pattern before writing code that manages heap memory or shared state. It maps common compiler errors to design questions about single versus shared ownership, single-threaded versus multi-threaded access, and reference-cycle risk. The skill triggers on Box, Rc, Arc, Weak, RefCell, Cell, RAII, Drop, and common comparison questions such as Box versus Rc or Arc versus Rc. Developers reach for m02-resource when Rust borrow-checker errors or ownership ambiguity block progress on backend services, CLI tools, or concurrent Rust code.
- Decision table mapping common errors to root design questions instead of quick fixes
- 3-step thinking prompt covering ownership model, thread context, and cycle detection
- Trace-up workflow that escalates pointer questions to higher-level architecture
- Explicit guidance on Box vs Rc vs Arc vs Weak, RefCell, Cell, and Drop patterns
- Bilingual triggers supporting both English and Chinese queries
M02 Resource by the numbers
- 795 all-time installs (skills.sh)
- +7 installs in the week ending Jul 28, 2026 (Skillselion tracking)
- Security screen: MEDIUM risk (skills.sh audit)
- Data as of Jul 28, 2026 (Skillselion catalog sync)
npx skills add https://github.com/zhanghandong/rust-skills --skill m02-resourceAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 795 |
|---|---|
| repo stars | ★ 1.3k |
| Security audit | 3 / 3 scanners passed |
| Last updated | May 24, 2026 |
| Repository | zhanghandong/rust-skills ↗ |
When should Rust code use Arc versus Rc?
Get systematic guidance on choosing and using Rust smart pointers before writing code that manages heap memory or shared state.
Who is it for?
Rust developers implementing heap allocation, reference counting, interior mutability, or shared state who need systematic pointer-selection guidance.
Skip if: Developers who need async runtime setup, Cargo workspace configuration, or non-Rust memory-management guidance.
When should I use this skill?
A developer asks which Rust smart pointer to use, hits borrow-checker errors around Rc/Arc/RefCell, or mentions heap allocation and shared ownership.
What you get
Selected smart-pointer pattern with ownership, threading, and cycle-risk rationale
- Smart-pointer recommendation
- Ownership-pattern rationale
Files
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 |
Related skills
Rust Async PatternsGenerate correct, production-grade async Rust code using Tokio, async-trait, channels, streams and proper error handling.16.3k38.3k
Rust Best PracticesGet concise, high-signal Rust style guidance that an agent can apply directly to code suggestions and reviews.14.5k100
Tauri V2Get expert guidance when creating cross-platform desktop and mobile apps using web technologies and Rust.6.5k14
Rust TestingGenerate comprehensive Rust tests following TDD with unit, integration, async, property-based, and mocked tests.5.8k234kRust PatternsGenerate and review idiomatic Rust code that follows ownership rules, error handling conventions, and concurrency best practices.5.4k234k
Rust SkillsEnsure every line of Rust they generate follows battle-tested idioms for ownership, error handling, performance and API design.3.6k367How it compares
Choose m02-resource over general Rust debugging skills when the core decision is which smart pointer and ownership pattern to adopt, not how to fix an unrelated compile error.
FAQ
Which Rust smart pointers does m02-resource cover?
m02-resource covers Box, Rc, Arc, Weak, RefCell, and Cell. It helps developers decide among them based on single versus shared ownership, threading model, and whether reference cycles are possible.
When should developers invoke m02-resource?
m02-resource should be invoked before writing Rust code that allocates on the heap or shares state across scopes. Common triggers include Box versus Rc questions, Arc versus Rc decisions, and RefCell borrow-checker failures.
Is M02 Resource safe to install?
skills.sh reports 3 of 3 security scanners passed. Review the Security Audits panel on this page before installing in production.