Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.
Instruções da origem · Visualização somente leitura
name
concurrent
description
Concurrency and parallelism. thread safety, race condition, deadlock, lock-free, async/await, actor model, mutex, goroutine.
Concurrent -- Concurrency & Parallelism
Activate When
User invokes /godmode:concurrent
User says "thread safety", "race condition", "deadlock", "lock-free"
User says "async/await", "actor model", "parallelism", "concurrent"
User says "mutex", "semaphore", "channel", "goroutine", "tokio"
When building multi-threaded or async systems
When /godmode:review flags potential race conditions or deadlocks
When /godmode:test reveals non-deterministic test failures
Workflow
Step 1: Concurrency Context Assessment
Understand the concurrency requirements before designing solutions:
CONCURRENCY CONTEXT:
Project: <name and purpose>
Language/Runtime: <Go | Rust | Node.js | Python | Java | Erlang/Elixir>
Concurrency Model: Threads | Green Threads | Event Loop | Actor Model | CSP
Current Issues: <race conditions, deadlocks, performance bottlenecks, none>
Shared State: <what mutable state is shared across concurrent units>
I/O Profile: CPU-bound | I/O-bound | Mixed
Scale: <concurrent connections/operations expected>
...
If the user has not provided context, ask: "What language/runtime are you using, and is the workload primarily
CPU-bound or I/O-bound? This determines the right concurrency model."
Step 2: Thread Safety Analysis
Identify shared mutable state and classify access patterns:
Design actor-based systems for message-driven concurrency:
ACTOR MODEL PRINCIPLES:
1. Each actor has private state -- no shared mutable state
2. Actors communicate only through asynchronous messages
3. Each actor processes one message at a time -- sequential within actor
4. Actors can create child actors, send messages, change behavior
ACTOR SYSTEM DESIGN:
| Actor | Messages Received | State | Children|
...
Step 7: Deadlock Detection and Prevention
Systematically prevent and detect deadlocks:
DEADLOCK CONDITIONS (all four must hold):
1. Mutual exclusion -- resource held exclusively
2. Hold and wait -- holding one resource, waiting for another
3. No preemption -- resources cannot be forcibly taken
4. Circular wait -- A waits for B, B waits for A
PREVENTION STRATEGIES:
| Strategy | Breaks Condition | How |
...
Step 8: Concurrent Testing Strategies
Verify correctness of concurrent code:
CONCURRENT TESTING APPROACH:
| Technique | What It Catches | Tools |
|--|--|--|
| Race detector | Data races | go -race, TSan |
| Stress testing | Intermittent bugs | Run N times |
| Loom (Rust) | All interleavings | loom crate |
| Property testing | Invariant violations | QuickCheck, Hypothesis |
| Linearizability | Correctness of | Jepsen, elle |
...
Step 9: Concurrency Model Selection
Choose the right concurrency model for the workload:
CONCURRENCY MODEL DECISION:
| Workload | Recommended Model | Language/Runtime |
|--|--|--|
| High I/O, many | Event loop / async | Node.js, Python |
| connections | | asyncio |
| CPU-bound parallel | Thread pool / rayon | Rust, Go, Java |
| Message-driven | Actor model | Erlang, Akka |
| distributed | | |
...
Step 10: Validation & Artifacts
Validate the concurrency design:
CONCURRENCY VALIDATION:
| Check | Status |
|--|--|
| All shared mutable state identified | PASS | FAIL |
| Protection strategy for each shared state| PASS | FAIL |
| Race condition analysis complete | PASS | FAIL |
| Deadlock prevention strategy in place | PASS | FAIL |
| Cancellation/shutdown paths verified | PASS | FAIL |
...
Commit: "concurrent: <feature> -- <model>, <N> shared states protected, <verdict>"
Quality Targets
Lock contention: <10ms per critical section
CPU utilization: >80% under load
Data race count: <1 detected by race detector
Key Behaviors
Never ask to continue. Loop autonomously until done.
# Run concurrency checks
go test -race ./...
cargo test -- --test-threads=1
python -m pytest tests/ -x --timeout=30
IF race detector reports > 0 races: fix before merging.
WHEN stress test (1000 iterations) shows any failure: investigate.
IF mutex hold time > 100ms: refactor to reduce critical section.
Identify shared mutable state first. Enumerate before coding.
Prefer message passing. Channels > mutexes.
Always use race detector. Run on every test. No exceptions.
Lock ordering prevents deadlocks. Document global order.
Flags & Options
Flag
Description
(none)
Full concurrency analysis and design
--analyze
Thread safety analysis of existing code
--race
Race condition detection and fixes
Auto-Detection
Detect language and concurrency model:
Go: goroutines+channels. Rust: tokio/async-std. Node: event loop.
Python: asyncio/threading. Java: threads/virtual threads.
## Keep/Discard Discipline
Each concurrency fix either passes the race detector or gets reverted.
- **KEEP**: Race detector clean, stress test (1000 iterations) passes, no new deadlock risk introduced.
- **DISCARD**: Fix introduces a new race, deadlock, or performance regression. Revert immediately.
- **CRASH**: Stress test reveals intermittent failure. Increase iterations to 10,000 to reproduce reliably, then fix.
- Log every analysis to `.godmode/concurrent-results.tsv`.
## Stop Conditions
