golang-concurrency

Guides writing and reviewing concurrent Go code using goroutines, channels, and sync primitives.

Updated Jun 30, 2026
One-click install
npx skills add https://github.com/santoshkal/chezmoi --skill golang-concurrency-santoshkal
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: golang-concurrency
Source: https://github.com/santoshkal/chezmoi/tree/main/private_dot_config/opencode/skills/Golang/skills/golang-concurrency
Command: npx skills add https://github.com/santoshkal/chezmoi --skill golang-concurrency-santoshkal

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Concurrent Go code is prone to goroutine leaks, race conditions, channel ownership bugs, and deadlocks that are hard to detect in review. This Skill encodes Go concurrency best practices so an AI coding agent writes and reviews concurrent code with correct lifecycle management, cancellation, and error propagation. ## Core Features & Use Cases - Write mode: Implements goroutines, channels, worker pools, and fan-out/fan-in pipelines following structured concurrency rules such as sender-closes-channel, ctx.Done() in every select, and errgroup.SetLimit for bounded concurrency. - Review mode: Audits PR diffs for goroutine leaks, missing context propagation, ownership violations, unprotected shared state, and WaitGroup misuse. - Audit mode: Orchestrates up to 5 parallel sub-agents to scan a codebase for goroutine spawns, mutable globals, channel misuse, and unsafe sync primitive usage. - Use Case: When asked to fetch 50 URLs with at most 10 concurrent requests and fail-fast behavior, it produces errgroup.WithContext plus SetLimit(10) instead of a hand-rolled worker pool. ## Quick Start Ask the agent to review this Go function for goroutine leaks and race conditions, or to write a bounded worker pool using errgroup.

Frequently Asked Questions about golang-concurrency

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I prevent goroutine leaks in Go?▼

Give every goroutine a clear exit path: pass a context.Context and include a ctx.Done() case in every select, or use a done channel. Pair spawns with sync.WaitGroup or errgroup so callers can wait, and verify with go.uber.org/goleak in TestMain.

When should I use errgroup instead of sync.WaitGroup?▼

Use errgroup when goroutines return errors, need cancellation of siblings on first failure, or need bounded concurrency via SetLimit. Use sync.WaitGroup only for simple fire-and-wait work with no error propagation; Go 1.25+ offers wg.Go for that case.

Should I use channels or mutexes for shared state in Go?▼

Use channels to transfer ownership of data between goroutines, and sync.Mutex or sync.RWMutex to protect shared struct fields. Use sync/atomic for simple counters and flags, and sync.Map only for write-once/read-many or disjoint-key workloads.

Why does closing a channel from the receiver panic in Go?▼

Only the sender may close a channel; if the receiver closes it, a subsequent send panics. To stop a producer early, the consumer signals through a separate done channel or context cancellation, and the producer selects on that signal while sending.

Is sync.Map always the right choice for concurrent maps?▼

No. sync.Map is optimized for write-once/read-many patterns or disjoint key sets. For write-heavy workloads with overlapping keys, a plain map guarded by sync.RWMutex is faster. Unsynchronized concurrent map access causes a hard crash, not just a data race.

How do I detect race conditions and goroutine leaks in Go tests?▼

Run tests with go test -race ./... to catch data races, and use go.uber.org/goleak in TestMain to fail tests that leak goroutines. For runtime inspection, use runtime.NumGoroutine() and the /debug/pprof/goroutine endpoint.