Concurrency safety
Skill saifoelloh/golang-best-practices-skill/concurrency-safety
Production-ready Go code review skill for AI agents based on authoritative sources
npx -y skills add saifoelloh/golang-best-practices-skill --skill concurrency-safetyAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 16 stars16 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Go concurrency safety review. Use when checking goroutines, channels, race conditions, or synchronization. Detects goroutine leaks, deadlocks, race conditions, and unsafe channel operations.
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
4.4 KB, as published. Nobody here has run it
Golang 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)