Go concurrency safety review. Use when checking goroutines, channels, race conditions, or synchronization. Detects goroutine leaks, deadlocks, race conditions, and unsafe channel operations.
Expert-level concurrency safety review for Go applications. Detects common concurrency bugs that cause production failures, race conditions, deadlocks, and resource leaks.
Use this skill when:
| Priority | Count | Focus |
|---|---|---|
| Critical | 5 | Prevents crashes, leaks, deadlocks |
| High | 4 | Correctness and reliability |
| Medium | 3 | Code quality and idioms |
critical-goroutine-leak - Goroutines must have exit conditionscritical-race-condition - Protect shared state with mutex/channelscritical-channel-deadlock - Ensure paired send/receive operationscritical-close-panic - Sender closes channel, not receivercritical-defer-in-loop - Avoid defer in loops (resource leaks)high-goroutine-unbounded - Limit concurrent goroutines (worker pool)high-channel-not-closed - Always close channels when donehigh-loop-variable-capture - Avoid closure over loop variableshigh-waitgroup-mismatch - Match Add() and Done() callsmedium-directional-channels - Use send/receive-only channelsmedium-buffered-channel-size - Choose appropriate buffer sizemedium-select-default - Avoid busy-wait with selectEach rule file in rules/ contains:
Example:
rules/critical-goroutine-leak.md
rules/high-channel-not-closed.md
This skill activates when you say:
Goroutine leak detection:
Check this code for goroutine leaks
Race condition audit:
Verify this concurrent code is safe
Channel safety review:
Review channel usage for deadlocks
When reviewing code, use this format:
## Critical Concurrency Issues: X
### [Rule Name] (Line Y)
**Issue**: Brief description
**Impact**: Race condition / Deadlock / Goroutine leak
**Fix**: Suggested correction
**Example**:
```go
// Corrected code here
[Similar format for high priority items]
[Similar format for medium priority items]
## Philosophy
Based on Katherine Cox-Buday's "Concurrency in Go":
- **Concurrency is not parallelism** - Design for coordination, not just speed
- **Channels are for communication** - Use for passing ownership
- **Mutexes are for state** - Use for protecting shared memory
- **Always have exit conditions** - Every goroutine must be able to stop
- **Context is the standard** - Use context.Context for cancellation
## Related Skills
- [golang-error-handling](../error-handling/SKILL.md) - For context propagation patterns
- [golang-clean-architecture](../clean-architecture/SKILL.md) - For usecase/repository concurrency patterns
## Notes
- Rules are evidence-based from authoritative Go concurrency books
- All examples are tested and production-ready
- Detection patterns help identify issues systematically
- Focused exclusively on concurrency safety (not general Go patterns)