Rust concurrency design: workload classification, sharing models, and Send/Sync requirements.
Works with
Guides decision-making between threads (CPU-bound), async (I/O-bound), and hybrid approaches before implementing
Covers Send/Sync marker traits, thread-safety patterns (Arc, Mutex, RwLock, channels), and atomic operations with quick reference tables
Includes mandatory \"trace up\" to domain skills (web, fintech, cloud-native, CLI) to align concurrency design with architectural constraints
AI-first code editor with Composer
Before installing skills in Cursor, ensure your development environment meets these requirements:
node --versionm07-concurrencyExecute the skills CLI command in your project's root directory to begin installation:
Fetches m07-concurrency from zhanghandong/rust-skills and configures it for Cursor.
The CLI shows a list of agents. Use arrow keys and space to select Cursor:
Confirm successful installation by checking the skill directory location:
Restart Cursor to activate m07-concurrency. Access via /m07-concurrency in your agent's command palette.
We perform automated surface-level scans (Gen AI Scanner, Socket, Snyk) during installation. These checks detect common vulnerabilities but do not guarantee complete security. Always review skill source code and verify the publisher's reputation before production use.
Skills execute code in your environment. Always review source, verify the publisher, and test in isolation before production.
Submit your Claude Code skill and start earning
Create detailed user stories, acceptance criteria, and feature specs
Example
Generate user stories for 'password reset feature' with acceptance criteria, edge cases, and test scenarios
Reduce spec writing time by 50%, ensure comprehensive coverage
Research competitors, compare features, identify gaps
Example
Analyze 5 competitor products, create feature comparison matrix, suggest differentiation opportunities
Complete competitive research in 2 hours instead of 2 days
Evaluate features using frameworks (RICE, ICE, Kano) and create prioritized backlogs
Example
Score 20 feature ideas using RICE framework, generate prioritized roadmap with rationale
0
total installs
0
this week
979
GitHub stars
0
upvotes
Run in your terminal
0
installs
0
this week
979
stars
Layer 1: Language Mechanics
Is this CPU-bound or I/O-bound, and what's the sharing model?
Before choosing concurrency primitives:
| 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? |
Before adding concurrency:
What's the workload?
What's the sharing model?
What are the Send/Sync requirements?
CRITICAL: Don't just fix the error. Trace UP to find domain constraints.
| Context Keywords | Load Domain Skill | Key Constraint |
|---|---|---|
| Web API, HTTP, axum, actix, handler | domain-web | Handlers run on any thread |
| 交易, 支付, trading, payment | domain-fintech | Audit + thread safety |
| gRPC, kubernetes, microservice | domain-cloud-native | Distributed tracing |
| CLI, terminal, clap | domain-cli | Usually single-thread OK |
"Rc cannot be sent between threads" in Web API context
↑ DETECT: "Web API" → Load domain-web
↑ FIND: domain-web says "Shared state must be thread-safe"
↑ FIND: domain-web says "Rc in state" is Common Mistake
↓ DESIGN: Use Arc<T> with State extractor
↓ IMPL: axum::extract::State<Arc<AppConfig>>
"Send not satisfied for my type"
↑ Ask: What domain is this? Load domain-* skill
↑ Ask: Does this type need to cross thread boundaries?
↑ Check: m09-domain (is the data model correct?)
| Situation | Trace To | Question |
|---|---|---|
| Send/Sync in Web | domain-web | What's the state management pattern? |
| Send/Sync in CLI | domain-cli | Is multi-thread really needed? |
| Mutex vs channels | m09-domain | Shared state or message passing? |
| Async vs threads | m10-performance | What's the workload profile? |
From design to implementation:
"Need parallelism for CPU work"
↓ Use: std::thread or rayon
"Need concurrency for I/O"
↓ Use: async/await with tokio
"Need to share immutable data across threads"
↓ Use: Arc<T>
"Need to share mutable data across threads"
↓ Use: Arc<Mutex<T>> or Arc<RwLock<T>>
↓ Or: channels for message passing
"Need simple atomic operations"
↓ Use: AtomicBool, AtomicUsize, etc.
| Marker | Meaning | Example |
|---|---|---|
Send |
Can transfer ownership between threads | Most types |
Sync |
Can share references between threads | Arc<T> |
!Send |
Must stay on one thread | Rc<T> |
!Sync |
No shared refs across threads | RefCell<T> |
| Pattern | Thread-Safe | Blocking | Use When |
|---|---|---|---|
std::thread |
Yes | Yes | CPU-bound parallelism |
async/await |
Yes | No | I/O-bound concurrency |
Mutex<T> |
Yes | Yes | Shared mutable state |
RwLock<T> |
Yes | Yes | Read-heavy shared state |
mpsc::channel |
Yes | Optional | Message passing |
Arc<Mutex<T>> |
Yes | Yes | Shared mutable across threads |
What type of work?
├─ CPU-bound → std::thread or rayon
├─ I/O-bound → async/await
└─ Mixed → hybrid (spawn_blocking)
Need to share data?
├─ No → message passing (channels)
├─ Immutable → Arc<T>
└─ Mutable →
├─ Read-heavy → Arc<RwLock<T>>
└─ Write-heavy → Arc<Mutex<T>>
└─ Simple counter → AtomicUsize
Async context?
├─ Type is Send → tokio::spawn
├─ Type is !Send → spawn_local
└─ Blocking code → spawn_blocking
| Error | Cause | Fix |
|---|---|---|
E0277 Send not satisfied |
Non-Send in async | Use Arc or spawn_local |
E0277 Sync not satisfied |
Non-Sync shared | Wrap with Mutex |
| Deadlock | Lock ordering | Consistent lock order |
future is not Send |
Non-Send across await | Drop before await |
MutexGuard across await |
Guard held during suspend | Scope guard properly |
| Anti-Pattern | Why Bad | Better |
|---|---|---|
| Arc<Mutex> everywhere | Contention, complexity | Message passing |
| thread::sleep in async | Blocks executor | tokio::time::sleep |
| Holding locks across await | Blocks other tasks | Scope locks tightly |
| Ignoring deadlock risk | Hard to debug | Lock ordering, try_lock |
// Bad: guard held across await
let guard = mutex.lock().await;
do_async().await; // guard still held!
// Good: scope the lock
{
let guard = mutex.lock().await;
// use guard
} // guard dropped
do_async().await;
// Rc is !Send, can't cross await in spawned task
// Option 1: use Arc instead
// Option 2: use spawn_local (single-thread runtime)
// Option 3: ensure Rc is dropped before .await
| When | See |
|---|---|
| Smart pointer choice | m02-resource |
| Interior mutability | m03-mutability |
| Performance tuning | m10-performance |
| Domain concurrency needs | domain-* |
Make data-driven prioritization decisions faster
Draft PRDs, status updates, and stakeholder presentations
Example
Create executive summary of Q3 roadmap, monthly progress report, feature launch announcement
Save 3-5 hours/week on communication overhead
Prerequisites
Time Estimate
30-60 minutes to see productivity improvements
Steps
Common Pitfalls
✓ Do
✗ Don't
💡 Pro Tips
✓ Use when
Use for user story writing, competitive research, roadmap prioritization, stakeholder communication, and PRD drafting. Best for reducing repetitive documentation and research work.
✗ Avoid when
Avoid for strategic product vision (requires deep customer empathy), pricing decisions (needs market and financial expertise), or when face-to-face customer discovery is more valuable than speed.
mattpocock/skills
parcadei/continuous-claude-v3
cursor/plugins
ailabs-393/ai-labs-claude-skills
pproenca/dot-skills
jezweb/claude-skills
We added m07-concurrency from the explainx registry; install was straightforward and the SKILL.md answered most questions upfront.
m07-concurrency fits our agent workflows well — practical, well scoped, and easy to wire into existing repos.
Useful defaults in m07-concurrency — fewer surprises than typical one-off scripts, and it plays nicely with `npx skills` flows.
m07-concurrency has been reliable in day-to-day use. Documentation quality is above average for community skills.
Useful defaults in m07-concurrency — fewer surprises than typical one-off scripts, and it plays nicely with `npx skills` flows.
m07-concurrency reduced setup friction for our internal harness; good balance of opinion and flexibility.
m07-concurrency fits our agent workflows well — practical, well scoped, and easy to wire into existing repos.
We added m07-concurrency from the explainx registry; install was straightforward and the SKILL.md answered most questions upfront.
Registry listing for m07-concurrency matched our evaluation — installs cleanly and behaves as described in the markdown.
Solid pick for teams standardizing on skills: m07-concurrency is focused, and the summary matches what you get after install.
showing 1-10 of 33