Cursor Skill

m02-resource

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, 智能指针, 引用计数, 堆分配

LLM Mart · 0 points · 7 views 0 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download moeru-ai-auv-.agents_skills_m02-resource-372a07b.zip · 1 KB
moeru-ai/auv 51 6 forks Apache-2.0 Updated 14h ago
Part of moeru-ai/auv — 28 skills

Install

skills CLI npx skills add https://github.com/moeru-ai/auv/tree/main/.agents/skills/m02-resource
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install moeru-ai-auv@llmmart
Git git clone https://github.com/moeru-ai/auv.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole moeru-ai/auv collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

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
Files (auv)
  • SKILL.md 4.3 KB
    ---
    name: m02-resource
    description: "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 |
    

Comments (0)

Sign in to join the conversation.

No comments yet.

Reviews (0)

No reviews yet.

Related