M03 Mutability
- 784 installs
- 1.3k repo stars
- Updated May 24, 2026
- zhanghandong/rust-skills
This is a copy of m03-mutability by actionbook - installs and ranking accrue to the original listing.
m03-mutability is a Rust agent skill that systematically resolves borrow checker and mutability errors—E0596, E0499, E0502—instead of blindly adding mut keywords for developers shipping safe Rust code.
About
m03-mutability is Layer 1 language mechanics guidance from zhanghandong/rust-skills for Rust mutability design. It triggers on compiler errors E0596, E0499, and E0502, plus phrases like cannot borrow as mutable, already borrowed as immutable, interior mutability, Cell, RefCell, Mutex, and RwLock. The skill reframes each error as a design question—who should mutate this data and is mutation essential—before recommending interior mutability patterns. Developers reach for m03-mutability when rustc blocks a build and adding mut or RefCell feels like a guess rather than an intentional ownership model.
- Translates compiler errors E0596, E0499, E0502 into precise design questions
- 3-layer decision framework: necessity, ownership control, and thread context
- Guides choice between &mut, Cell, RefCell, Mutex, RwLock and immutable alternatives
- Prevents accidental complexity from premature interior mutability
- Includes error-to-question mapping table and upward tracing prompts
M03 Mutability by the numbers
- 784 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 m03-mutabilityAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 784 |
|---|---|
| repo stars | ★ 1.3k |
| Security audit | 3 / 3 scanners passed |
| Last updated | May 24, 2026 |
| Repository | zhanghandong/rust-skills ↗ |
How do you fix Rust borrow checker mutability errors?
Systematically resolve Rust borrow checker and mutability errors instead of blindly adding `mut` keywords.
Who is it for?
Rust developers blocked by E0596, E0499, or E0502 who need ownership-aware fixes instead of sprinkling mut everywhere.
Skip if: Greenfield Rust tutorials with no active compiler errors or projects already standardized on a concurrency crate.
When should I use this skill?
Rust compilation fails with E0596, E0499, E0502, cannot borrow as mutable, or interior mutability keywords appear in the error or user message.
What you get
Resolved borrow errors, an intentional mutability design, and compiles-safe use of mut, references, or interior mutability types.
- fixed ownership model
- compiling Rust source
By the numbers
- Documents three primary Rust error codes: E0596, E0499, E0502
- Covers four interior mutability types: Cell, RefCell, Mutex, RwLock
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:
1. Is mutation necessary?
- Maybe transform → return new value
- Maybe builder → construct immutably
2. Who controls mutation?
- External caller →
&mut T - Internal logic → interior mutability
- Concurrent access → synchronized mutability
3. What's the thread context?
- Single-thread → Cell/RefCell
- Multi-thread → Mutex/RwLock/Atomic
---
Trace Up ↑
When mutability conflicts persist:
E0499/E0502 (borrow conflicts)
↑ Ask: Is the data structure designed correctly?
↑ Check: m09-domain (should data be split?)
↑ Check: m07-concurrency (is async involved?)| Persistent Error | Trace To | Question |
|---|---|---|
| Repeated borrow conflicts | m09-domain | Should data be restructured? |
| RefCell in async | m07-concurrency | Is Send/Sync needed? |
| Mutex deadlocks | m07-concurrency | Is the lock design right? |
---
Trace Down ↓
From design to implementation:
"Need mutable access from &self"
↓ T: Copy → Cell<T>
↓ T: !Copy → RefCell<T>
"Need thread-safe mutation"
↓ Simple counters → AtomicXxx
↓ Complex data → Mutex<T> or RwLock<T>
"Need shared mutable state"
↓ Single-thread: Rc<RefCell<T>>
↓ Multi-thread: Arc<Mutex<T>>---
Borrow Rules
At any time, you can have EITHER:
├─ Multiple &T (immutable borrows)
└─ OR one &mut T (mutable borrow)
Never both simultaneously.Quick Reference
| Pattern | Thread-Safe | Runtime Cost | Use When |
|---|---|---|---|
&mut T | N/A | Zero | Exclusive mutable access |
Cell<T> | No | Zero | Copy types, no refs needed |
RefCell<T> | No | Runtime check | Non-Copy, need runtime borrow |
Mutex<T> | Yes | Lock contention | Thread-safe mutation |
RwLock<T> | Yes | Lock contention | Many readers, few writers |
Atomic* | Yes | Minimal | Simple types (bool, usize) |
Error Code Reference
| Error | Cause | Quick Fix |
|---|---|---|
| E0596 | Borrowing immutable as mutable | Add mut or redesign |
| E0499 | Multiple mutable borrows | Restructure code flow |
| E0502 | &mut while & exists | Separate borrow scopes |
---
Interior Mutability Decision
| Scenario | Choose |
|---|---|
| T: Copy, single-thread | Cell<T> |
| T: !Copy, single-thread | RefCell<T> |
| T: Copy, multi-thread | AtomicXxx |
| T: !Copy, multi-thread | Mutex<T> or RwLock<T> |
| Read-heavy, multi-thread | RwLock<T> |
| Simple flags/counters | AtomicBool, AtomicUsize |
---
Anti-Patterns
| Anti-Pattern | Why Bad | Better |
|---|---|---|
| RefCell everywhere | Runtime panics | Clear ownership design |
| Mutex for single-thread | Unnecessary overhead | RefCell |
| Ignore RefCell panic | Hard to debug | Handle or restructure |
| Lock inside hot loop | Performance killer | Batch operations |
---
Related Skills
| When | See |
|---|---|
| Smart pointer choice | m02-resource |
| Thread safety | m07-concurrency |
| Data structure design | m09-domain |
| Anti-patterns | m15-anti-pattern |
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
Use m03-mutability for ownership design decisions; use generic Rust debug skills when errors are unrelated to borrowing or mutation.
FAQ
Which errors does m03-mutability handle?
m03-mutability targets Rust compiler errors E0596, E0499, and E0502, along with messages like cannot borrow as mutable and already borrowed as immutable. It also covers interior mutability with Cell, RefCell, Mutex, and RwLock.
Should m03-mutability just add mut?
m03-mutability explicitly warns against blindly adding mut. The skill asks why data must change and who controls mutation before choosing references, mut bindings, or interior mutability primitives.
Is M03 Mutability safe to install?
skills.sh reports 3 of 3 security scanners passed. Review the Security Audits panel on this page before installing in production.