Go Concurrency

This covers the practical side of Go's concurrency model: when to spawn goroutines, how to make sure they stop, and whether to reach for channels or mutexes. The core rule is simple: never start a goroutine without knowing how it will stop. You'll find normative guidance on goroutine lifetimes, WaitGroup patterns, channel direction, and atomic operations, plus references to leak detection with goleak. It pushes you toward synchronous functions by default and letting callers add concurrency when needed. The channel sizing rule is refreshingly blunt: zero or one, anything else needs written justification. Good for teams that want to avoid the classic pitfalls like goroutine leaks, blocked channels, and races on shared state.

skills.sh installs: 1.3K
GitHub stars: 193
last updated: Aug 21, 2026

View on GitHub

Install

$ npx -y skills add cxuu/golang-skills --skill go-concurrency --agent claude-code

Installs into .claude/skills of the current project.

Files

Go Concurrency

Compatibility: Atomic examples may use standard-library typed atomics where available or go.uber.org/atomic where a project already depends on it.

Resource Routing

references/GOROUTINE-PATTERNS.md - Read when starting, stopping, or waiting for goroutines.
references/SYNC-PRIMITIVES.md - Read when choosing between mutexes, atomics, channels, and once-like primitives.
references/BUFFER-POOLING.md - Read when considering channel-backed or sync.Pool-style reuse.
references/ADVANCED-PATTERNS.md - Read for worker pools, pipelines, errgroup, and cancellation-heavy patterns.

Goroutine Lifetimes

Normative: When you spawn goroutines, make it clear when or whether they exit.

Goroutines can leak by blocking on channel sends/receives. The GC will not terminate a blocked goroutine even if no other goroutine holds a reference to the channel. Even non-leaking in-flight goroutines cause panics (send on closed channel), data races, memory issues, and resource leaks.