m01-ownership

CRITICAL: Use for ownership/borrow/lifetime issues. Triggers: E0382, E0597, E0506, E0507, E0515, E0716, E0106, value moved, borrowed value does not live long…

INSTALLATION
npx skills add https://github.com/actionbook/rust-skills --skill m01-ownership
Run in your project or agent environment. Adjust flags if your CLI version differs.

SKILL.md

Ownership & Lifetimes

Layer 1: Language Mechanics

Core Question

Who should own this data, and for how long?

Before fixing ownership errors, understand the data's role:

  • Is it shared or exclusive?
  • Is it short-lived or long-lived?
  • Is it transformed or just read?

Error → Design Question

Error

Don't Just Say

Ask Instead

E0382

"Clone it"

Who should own this data?

E0597

"Extend lifetime"

Is the scope boundary correct?

E0506

"End borrow first"

Should mutation happen elsewhere?

E0507

"Clone before move"

Why are we moving from a reference?

E0515

"Return owned"

Should caller own the data?

E0716

"Bind to variable"

Why is this temporary?

E0106

"Add 'a"

What is the actual lifetime relationship?

Thinking Prompt

Before fixing an ownership error, ask:

-

What is this data's domain role?

  • Entity (unique identity) → owned
  • Value Object (interchangeable) → clone/copy OK
  • Temporary (computation result) → maybe restructure

-

Is the ownership design intentional?

  • By design → work within constraints
  • Accidental → consider redesign

-

Fix symptom or redesign?

  • If Strike 3 (3rd attempt) → escalate to Layer 2

Trace Up ↑

When errors persist, trace to design layer:

E0382 (moved value)

    ↑ Ask: What design choice led to this ownership pattern?

    ↑ Check: m09-domain (is this Entity or Value Object?)

    ↑ Check: domain-* (what constraints apply?)

Persistent Error

Trace To

Question

E0382 repeated

m02-resource

Should use Arc/Rc for sharing?

E0597 repeated

m09-domain

Is scope boundary at right place?

E0506/E0507

m03-mutability

Should use interior mutability?

Trace Down ↓

From design decisions to implementation:

"Data needs to be shared immutably"

    ↓ Use: Arc<T> (multi-thread) or Rc<T> (single-thread)

"Data needs exclusive ownership"

    ↓ Use: move semantics, take ownership

"Data is read-only view"

    ↓ Use: &#x26;T (immutable borrow)

Quick Reference

Pattern

Ownership

Cost

Use When

Move

Transfer

Zero

Caller doesn't need data

&#x26;T

Borrow

Zero

Read-only access

&#x26;mut T

Exclusive borrow

Zero

Need to modify

clone()

Duplicate

Alloc + copy

Actually need a copy

Rc<T>

Shared (single)

Ref count

Single-thread sharing

Arc<T>

Shared (multi)

Atomic ref count

Multi-thread sharing

Cow<T>

Clone-on-write

Alloc if mutated

Might modify

Error Code Reference

Error

Cause

Quick Fix

E0382

Value moved

Clone, reference, or redesign ownership

E0597

Reference outlives owner

Extend owner scope or restructure

E0506

Assign while borrowed

End borrow before mutation

E0507

Move out of borrowed

Clone or use reference

E0515

Return local reference

Return owned value

E0716

Temporary dropped

Bind to variable

E0106

Missing lifetime

Add 'a annotation

Anti-Patterns

Anti-Pattern

Why Bad

Better

.clone() everywhere

Hides design issues

Design ownership properly

Fight borrow checker

Increases complexity

Work with the compiler

'static for everything

Restricts flexibility

Use appropriate lifetimes

Leak with Box::leak

Memory leak

Proper lifetime design

Related Skills

When

See

Need smart pointers

m02-resource

Need interior mutability

m03-mutability

Data is domain entity

m09-domain

Learning ownership concepts

m14-mental-model

BrowserAct

Let your agent run on any real-world website

Bypass CAPTCHA & anti-bot for free. Start local, scale to cloud.

Explore BrowserAct Skills →

Stop writing automation&scrapers

Install the CLI. Run your first Skill in 30 seconds. Scale when you're ready.

Start free
free · no credit card