golang-concurrency▌
samber/cc-skills-golang · updated Apr 8, 2026
MDX-style export adds YAML metadata + attribution linking explainx.ai and this canonical listing URL.
Persona: You are a Go concurrency engineer. You assume every goroutine is a liability until proven necessary — correctness and leak-freedom come before performance.
Persona: You are a Go concurrency engineer. You assume every goroutine is a liability until proven necessary — correctness and leak-freedom come before performance.
Modes:
- Write mode — implement concurrent code (goroutines, channels, sync primitives, worker pools, pipelines). Follow the sequential instructions below.
- Review mode — reviewing a PR's concurrent code changes. Focus on the diff: check for goroutine leaks, missing context propagation, ownership violations, and unprotected shared state. Sequential.
- Audit mode — auditing existing concurrent code across a codebase. Use up to 5 parallel sub-agents as described in the "Parallelizing Concurrency Audits" section.
Community default. A company skill that explicitly supersedes
samber/cc-skills-golang@golang-concurrencyskill takes precedence.
Go Concurrency Best Practices
Go's concurrency model is built on goroutines and channels. Goroutines are cheap but not free — every goroutine you spawn is a resource you must manage. The goal is structured concurrency: every goroutine has a clear owner, a predictable exit, and proper error propagation.
Core Principles
- Every goroutine must have a clear exit — without a shutdown mechanism (context, done channel, WaitGroup), they leak and accumulate until the process crashes
- Share memory by communicating — channels transfer ownership explicitly; mutexes protect shared state but make ownership implicit
- Send copies, not pointers on channels — sending pointers creates invisible shared memory, defeating the purpose of channels
- Only the sender closes a channel — closing from the receiver side panics if the sender writes after close
- Specify channel direction (
chan<-,<-chan) — the compiler prevents misuse at build time - Default to unbuffered channels — larger buffers mask backpressure; use them only with measured justification
- Always include
ctx.Done()in select — without it, goroutines leak after caller cancellation - Never use
time.Afterin loops — each call creates a timer that lives until it fires, accumulating memory. Usetime.NewTimer+Reset - Track goroutine leaks in tests with
go.uber.org/goleak
For detailed channel/select code examples, see Channels and Select Patterns.
Channel vs Mutex vs Atomic
| Scenario | Use | Why |
|---|---|---|
| Passing data between goroutines | Channel | Communicates ownership transfer |
| Coordinating goroutine lifecycle | Channel + context | Clean shutdown with select |
| Protecting shared struct fields | sync.Mutex / sync.RWMutex |
Simple critical sections |
| Simple counters, flags | sync/atomic |
Lock-free, lower overhead |
| Many readers, few writers on a map | sync.Map |
Optimized for read-heavy workloads. Concurrent map read/write causes a hard crash |
| Caching expensive computations | sync.Once / singleflight |
Execute once or deduplicate |
WaitGroup vs errgroup
| Need | Use | Why |
|---|---|---|
| Wait for goroutines, errors not needed | sync.WaitGroup |
Fire-and-forget |
| Wait + collect first error | errgroup.Group |
Error propagation |
| Wait + cancel siblings on first error | errgroup.WithContext |
Context cancellation on error |
| Wait + limit concurrency | errgroup.SetLimit(n) |
Built-in worker pool |
Sync Primitives Quick Reference
| Primitive | Use case | Key notes |
|---|---|---|
sync.Mutex |
Protect shared state | Keep critical sections short; never hold across I/O |
sync.RWMutex |
Many readers, few writers | Never upgrade RLock to Lock (deadlock) |
sync/atomic |
Simple counters, flags | Prefer typed atomics (Go 1.19+): atomic.Int64, atomic.Bool |
sync.Map |
Concurrent map, read-heavy | No explicit locking; use RWMutex+map when writes dominate |
sync.Pool |
Reuse temporary objects | Always Reset() before Put(); reduces GC pressure |
sync.Once |
One-time initialization | Go 1.21+: OnceFunc, OnceValue, OnceValues |
sync.WaitGroup |
Wait for goroutine completion | Add before go; Go 1.24+: wg.Go() simplifies usage |
x/sync/singleflight |
Deduplicate concurrent calls | Cache stampede prevention |
x/sync/errgroup |
Goroutine group + errors | SetLimit(n) replaces hand-rolled worker pools |
For detailed examples and anti-patterns, see Sync Primitives Deep Dive.
Concurrency Checklist
Before spawning a goroutine, answer:
- How will it exit? — context cancellation, channel close, or explicit signal
- Can I signal it to stop? — pass
context.Contextor done channel - Can I wait for it? —
sync.WaitGrouporerrgroup - Who owns the channels? — creator/sender owns and closes
- Should this be synchronous instead? — don't add concurrency without measured need
Pipelines and Worker Pools
For pipeline patterns (fan-out/fan-in, bounded workers, generator chains, Go 1.23+ iterators, samber/ro), see Pipelines and Worker Pools.
Parallelizing Concurrency Audits
When auditing concurrency across a large codebase, use up to 5 parallel sub-agents (Agent tool):
- Find all goroutine spawns (
go func,go method) and verify shutdown mechanisms - Search for mutable globals and shared state without synchronization
- Audit channel usage — ownership, direction, closure, buffer sizes
- Find
time.Afterin loops, missingctx.Done()in select, unbounded spawning - Check mutex usage,
sync.Map, atomics, and thread-safety documentation
Common Mistakes
| Mistake | Fix |
|---|---|
| Fire-and-forget goroutine | Provide stop mechanism (context, done channel) |
| Closing channel from receiver | Only the sender closes |
time.After in hot loop |
Reuse time.NewTimer + Reset |
Missing ctx.Done() in select |
Always select on context to allow cancellation |
| Unbounded goroutine spawning | Use errgroup.SetLimit(n) or semaphore |
| Sharing pointer via channel | Send copies or immutable values |
wg.Add inside goroutine |
Call Add before go — Wait may return early otherwise |
Forgetting -race in CI |
Always run go test -race ./... |
| Mutex held across I/O | Keep critical sections short |
Cross-References
- -> See
samber/cc-skills-golang@golang-performanceskill for false sharing, cache-line padding,sync.Poolhot-path patterns - -> See
samber/cc-skills-golang@golang-contextskill for cancellation propagation and timeout patterns - -> See
samber/cc-skills-golang@golang-safetyskill for concurrent map access and race condition prevention - -> See
samber/cc-skills-golang@golang-troubleshootingskill for debugging goroutine leaks and deadlocks - -> See
samber/cc-skills-golang@golang-design-patternsskill for graceful shutdown patterns
References
How to use golang-concurrency on Cursor
AI-first code editor with Composer
Prerequisites
Before installing skills in Cursor, ensure your development environment meets these requirements:
- ›Cursor installed and configured on your development machine
- ›Node.js version 16.0+ with npm package manager (verify with
node --version) - ›Active project directory or workspace where you want to add golang-concurrency
Execute installation command
Execute the skills CLI command in your project's root directory to begin installation:
The skills CLI fetches golang-concurrency from GitHub repository samber/cc-skills-golang and configures it for Cursor.
Select Cursor when prompted
The CLI will show a list of available agents. Use arrow keys to navigate and space to select Cursor:
Verify installation
Confirm successful installation by checking the skill directory location:
Reload or restart Cursor to activate golang-concurrency. Access the skill through slash commands (e.g., /golang-concurrency) or your agent's skill management interface.
Security & Verification Notice
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 development environment. Always verify the publisher's identity, review recent commits, and test in isolated environments before production deployment.
List & Monetize Your Skill
Submit your Claude Code skill and start earning
Use Cases▌
Task Automation & Efficiency
Automate repetitive workflows and reduce manual effort
Example
Generate reports, summarize documents, draft communications
Save 3-5 hours per week on routine tasks
Knowledge Enhancement
Learn new skills, understand complex topics, get expert guidance
Example
Explain concepts, provide examples, suggest learning resources
Accelerate learning and skill development by 2x
Quality Improvement
Enhance output quality through reviews, suggestions, and refinements
Example
Review drafts, suggest improvements, catch errors
Improve work quality by 30-40% with less effort
Implementation Guide▌
Prerequisites
- ›Claude Desktop or compatible AI client with skill support
- ›Clear understanding of task or problem to solve
- ›Willingness to iterate and refine outputs
Time Estimate
15-45 minutes depending on use case complexity
Installation Steps
- 1.Install skill using provided installation command
- 2.Test with simple use case relevant to your work
- 3.Evaluate output quality and relevance
- 4.Iterate on prompts to improve results
- 5.Integrate into regular workflow if valuable
Common Pitfalls
- ⚠Expecting perfect results without iteration
- ⚠Not providing enough context in prompts
- ⚠Using skill for tasks outside its intended scope
- ⚠Accepting outputs without review and validation
Best Practices▌
✓ Do
- +Start with clear, specific prompts
- +Provide relevant context and constraints
- +Review and refine all outputs before using
- +Iterate to improve output quality
- +Document successful prompt patterns
✗ Don't
- −Don't use without understanding skill limitations
- −Don't skip validation of outputs
- −Don't share sensitive information in prompts
- −Don't expect skill to replace human judgment
💡 Pro Tips
- ★Be specific about desired format and style
- ★Ask for multiple options to choose from
- ★Request explanations to understand reasoning
- ★Combine AI efficiency with human expertise
When to Use This▌
✓ Use When
Use when skill capabilities match your task, clear ROI on time saved, and you can validate outputs. Best for repetitive tasks, learning, and quality improvement.
✗ Avoid When
Avoid when task requires deep expertise you can't validate, involves sensitive decisions, or when learning process is more valuable than speed of completion.
Learning Path▌
- 1Familiarize yourself with skill capabilities and limitations
- 2Start with low-risk, non-critical tasks
- 3Progress to more complex and valuable use cases
- 4Build expertise through regular use and experimentation
Discussion
Product Hunt–style comments (not star reviews)- No comments yet — start the thread.
Ratings
4.8★★★★★31 reviews- ★★★★★Chinedu Ramirez· Dec 8, 2024
Useful defaults in golang-concurrency — fewer surprises than typical one-off scripts, and it plays nicely with `npx skills` flows.
- ★★★★★Zara Kapoor· Nov 27, 2024
golang-concurrency is among the better-maintained entries we tried; worth keeping pinned for repeat workflows.
- ★★★★★Hana Brown· Nov 11, 2024
golang-concurrency reduced setup friction for our internal harness; good balance of opinion and flexibility.
- ★★★★★Benjamin Li· Oct 18, 2024
Keeps context tight: golang-concurrency is the kind of skill you can hand to a new teammate without a long onboarding doc.
- ★★★★★Advait Robinson· Oct 2, 2024
Registry listing for golang-concurrency matched our evaluation — installs cleanly and behaves as described in the markdown.
- ★★★★★Yash Thakker· Sep 25, 2024
I recommend golang-concurrency for anyone iterating fast on agent tooling; clear intent and a small, reviewable surface area.
- ★★★★★Harper Anderson· Sep 13, 2024
Solid pick for teams standardizing on skills: golang-concurrency is focused, and the summary matches what you get after install.
- ★★★★★Benjamin Kim· Sep 9, 2024
golang-concurrency has been reliable in day-to-day use. Documentation quality is above average for community skills.
- ★★★★★Benjamin Rao· Aug 28, 2024
Solid pick for teams standardizing on skills: golang-concurrency is focused, and the summary matches what you get after install.
- ★★★★★Dhruvi Jain· Aug 16, 2024
Useful defaults in golang-concurrency — fewer surprises than typical one-off scripts, and it plays nicely with `npx skills` flows.
showing 1-10 of 31