golang-concurrency-safety
Scannednpx machina-cli add skill saifoelloh/golang-best-practices-skill/concurrency-safety --openclawGolang Concurrency Safety
Expert-level concurrency safety review for Go applications. Detects common concurrency bugs that cause production failures, race conditions, deadlocks, and resource leaks.
When to Apply
Use this skill when:
- Reviewing code with goroutines or channels
- Debugging race conditions or deadlocks
- Auditing concurrent data access
- Investigating goroutine leaks or memory issues
- Writing new concurrent code
- Preparing concurrent code for production
Rule Categories by Priority
| Priority | Count | Focus |
|---|---|---|
| Critical | 5 | Prevents crashes, leaks, deadlocks |
| High | 4 | Correctness and reliability |
| Medium | 3 | Code quality and idioms |
Rules Covered (12 total)
Critical Issues (5)
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-Impact Patterns (4)
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() calls
Medium Improvements (3)
medium-directional-channels- Use send/receive-only channelsmedium-buffered-channel-size- Choose appropriate buffer sizemedium-select-default- Avoid busy-wait with select
How to Use
For Code Review
- Scan code for goroutine launches and channel operations
- Check against rules in priority order (Critical first)
- For each violation found, reference the specific rule file
- Provide exact line numbers and explanation
- Show corrected code example
Accessing Detailed Rules
Each rule file in rules/ contains:
- Brief explanation of why it matters
- Detection criteria (how to spot the issue)
- Incorrect code example (❌ BAD)
- Correct code example (✅ GOOD)
- Impact assessment
- References
Example:
rules/critical-goroutine-leak.md
rules/high-channel-not-closed.md
Trigger Phrases
This skill activates when you say:
- "Check for race conditions"
- "Review concurrency"
- "Find goroutine leaks"
- "Check for deadlocks"
- "Review channel usage"
- "Audit goroutine safety"
- "Check synchronization"
- "Review concurrent code"
Common Patterns
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
Output Format
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
High-Impact Patterns: X
[Similar format for high priority items]
Medium Improvements: X
[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)
Source
git clone https://github.com/saifoelloh/golang-best-practices-skill/blob/main/concurrency-safety/SKILL.mdView on GitHub Overview
Expert-level Go concurrency safety review to detect goroutine leaks, race conditions, deadlocks, and unsafe channel usage. It helps teams prevent production failures by auditing goroutine lifecycles, synchronization patterns, and channel operations.
How This Skill Works
The skill scans code for goroutine launches, channel usage, and shared-state access. It applies a prioritized rule set (Critical first), referencing the skill's detailed rule files to pinpoint violations and provide corrected examples for fixes such as leaks, deadlocks, and race conditions.
When to Use It
- Review code that uses goroutines or channels
- Debug race conditions or deadlocks
- Audit concurrent data access
- Investigate goroutine leaks or memory issues
- Prepare new concurrent code for production
Quick Start
- Step 1: Scan code for goroutine launches and channel operations
- Step 2: Apply critical issue checks first; record exact lines and explanations
- Step 3: Provide corrected code examples and reference the corresponding rule files
Best Practices
- Prioritize Critical Issues first to catch leaks, races, and deadlocks
- Ensure every goroutine has a clear exit path and cancellation signals
- Close channels when done and design producers to close (not receivers)
- Balance WaitGroup Add() and Done() calls to avoid leaks
- Avoid defer in loops and closure over loop variables; use directional channels and appropriate buffers
Example Use Cases
- Goroutine leak detected in a worker pool due to missing exit condition
- Race condition on a shared counter without proper mutex protection
- Deadlock caused by unbalanced send/receive operations across goroutines
- Unsafe channel close when the receiver handles closure after producer finishes
- WaitGroup timeout or mismatch leading to stuck goroutines