M07 Concurrency

This is your concurrency troubleshooting companion that stops you from blindly wrapping everything in Arc<Mutex<T>>. It intercepts those dreaded E0277 Send/Sync errors and forces you to ask whether you actually need threads at all. The trace up/trace down model is solid: it connects compiler errors to domain constraints (like why Rc fails in web handlers) and walks you through CPU-bound versus I/O-bound decisions before you reach for primitives. The error-to-design-question table is the real value here, turning "Future not Send" into "Is async the right choice?" instead of just adding bounds until it compiles. Particularly strong on the async footguns like holding MutexGuard across await points.

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

View on GitHub

Install

$ npx -y skills add actionbook/rust-skills --skill m07-concurrency --agent claude-code

Installs into .claude/skills of the current project.

Files

Concurrency

Layer 1: Language Mechanics

Core Question

Is this CPU-bound or I/O-bound, and what's the sharing model?

Before choosing concurrency primitives:

What's the workload type?
What data needs to be shared?
What's the thread safety requirement?

Error → Design Question

Error	Don't Just Say	Ask Instead
E0277 Send	"Add Send bound"	Should this type cross threads?
E0277 Sync	"Wrap in Mutex"	Is shared access really needed?
Future not Send	"Use spawn_local"	Is async the right choice?
Deadlock	"Reorder locks"	Is the locking design correct?

Thinking Prompt

Before adding concurrency:

What's the workload?
- CPU-bound → threads (std::thread, rayon)
- I/O-bound → async (tokio, async-std)
- Mixed → hybrid approach
What's the sharing model?
- No sharing → message passing (channels)
- Immutable sharing → Arc
- Mutable sharing → Arc<Mutex> or Arc<RwLock>
What are the Send/Sync requirements?
- Cross-thread ownership → Send
- Cross-thread references → Sync
- Single-thread async → spawn_local