M03 Mutability

This is your go-to when the borrow checker is yelling at you about E0596, E0499, or E0502. Instead of just slapping `mut` everywhere or reaching for RefCell, it walks you through the actual design question: does this data really need to change, and who should control that mutation? The decision trees are solid, like mapping from "need mutable access from &self" straight to Cell vs RefCell based on Copy, or choosing between Rc<RefCell<T>> and Arc<Mutex<T>> based on threading. The anti-patterns section alone will save you from runtime panics. Honestly, this reframes mutability errors from compiler complaints into architecture decisions, which is the right way to think about Rust's ownership model anyway.

skills.sh installs: 3.6K
GitHub stars: 1.6K
last updated: Aug 21, 2026

View on GitHub

Install

$ npx -y skills add actionbook/rust-skills --skill m03-mutability --agent claude-code

Installs into .claude/skills of the current project.

Files

Mutability

Layer 1: Language Mechanics

Core Question

Why does this data need to change, and who can change it?

Before adding interior mutability, understand:

Is mutation essential or accidental complexity?
Who should control mutation?
Is the mutation pattern safe?

Error → Design Question

Error	Don't Just Say	Ask Instead
E0596	"Add mut"	Should this really be mutable?
E0499	"Split borrows"	Is the data structure right?
E0502	"Separate scopes"	Why do we need both borrows?
RefCell panic	"Use try_borrow"	Is runtime check appropriate?

Thinking Prompt

Before adding mutability:

Is mutation necessary?
- Maybe transform → return new value
- Maybe builder → construct immutably
Who controls mutation?
- External caller → &mut T
- Internal logic → interior mutability
- Concurrent access → synchronized mutability
What's the thread context?
- Single-thread → Cell/RefCell
- Multi-thread → Mutex/RwLock/Atomic