Skill v1.0.1

currentAutomated scan100/100

zhanghandong/rust-skills/m01-ownership

3 files

──Details

PublishedMay 15, 2026 at 02:52 AM

Content Hashsha256:cb4ebbeefbbace5f...

Git SHA37e050f490a7

Bump Typepatch

Compare with v1.0.0

──Files

Files (1 file, 4.1 KB)

SKILL.md4.1 KBactive

SKILL.md · 136 lines · 4.1 KB

version: "1.0.1" name: m01-ownership description: "CRITICAL: Use for ownership/borrow/lifetime issues. Triggers: E0382, E0597, E0506, E0507, E0515, E0716, E0106, value moved, borrowed value does not live long enough, cannot move out of, use of moved value, ownership, borrow, lifetime, 'a, 'static, move, clone, Copy, 所有权, 借用, 生命周期" user-invocable: false

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: &T (immutable borrow)

Quick Reference

Pattern	Ownership	Cost	Use When
Move	Transfer	Zero	Caller doesn't need data
`&T`	Borrow	Zero	Read-only access
`&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

← v1.0.0 All versions