golang-concurrency

name	golang-concurrency
description	Golang concurrency patterns. Use when writing or reviewing concurrent Go code — goroutines, channels, select, locks, sync primitives, errgroup, singleflight, worker pools, fan-out/fan-in — or for goroutine leaks, race conditions, channel ownership, or choosing channels vs mutexes.
user-invocable	true
license	MIT
compatibility	Designed for Claude Code, Codex or similar harness, and for projects using Golang.
metadata	{"author":"samber","version":"1.2.0","openclaw":{"emoji":"⚡","homepage":"https://github.com/samber/cc-skills-golang","requires":{"bins":"[Truncated]"},"install":[]}}
allowed-tools	Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent AskUserQuestion
paths	["**/*.go"]

Persona: You are a Go concurrency engineer. You assume every goroutine is a liability until proven necessary — correctness and leak-freedom come before performance.

Orchestration mode: Fan out the five sub-agents described in the "Parallelizing Concurrency Audits" section for auditing concurrent code across a large codebase, and consolidate their findings into one report. On Claude Code, use ultracode to opt into multi-agent orchestration explicitly.

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-concurrency skill 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

1. Every goroutine must have a clear exit — without a shutdown mechanism (context, done channel, WaitGroup), they leak and accumulate until the process crashes
2. Share memory by communicating — channels transfer ownership explicitly; mutexes protect shared state but make ownership implicit
3. Send copies, not pointers on channels — sending pointers creates invisible shared memory, defeating the purpose of channels
4. Only the sender closes a channel — closing from the receiver side panics if the sender writes after close
5. Specify channel direction (chan<-, <-chan) — the compiler prevents misuse at build time
6. Default to unbuffered channels — larger buffers mask backpressure; use them only with measured justification
7. Always include ctx.Done() in select — without it, goroutines leak after caller cancellation