golang-concurrency

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.

Ir para a instalação

Repositório: context-labs/whip
Última atividade na origem: 24 de agosto de 2026 às 04:15
Idioma detectado do SKILL.md: inglês
Estrelas: 205
Forks: 21

Opções de instalação

Por padrão, está selecionado o prompt que primeiro revisa a origem. Você pode mudar para um comando direto ou baixar uma cópia local.

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.

npx skills add https://github.com/context-labs/whip --skill golang-concurrency

O comando permanece em uma só linha. Role horizontalmente para revisá-lo antes de copiar.

Prefere uma cópia local? Baixe os arquivos disponíveis atualmente no SkillsMP.

Revise os arquivos de origem

Leia o SKILL.md e os arquivos complementares exibidos pelo SkillsMP antes de decidir se vai instalar.

Explorador de arquivos

5 arquivos

SKILL.md

Instruções da origem · Visualização somente leitura

Voltar à pesquisa Voltar à instalação

new-feature-development

Playbook for building a NET-NEW feature in whip. Use when the user wants to add a feature, tool, slash command, integration, or UX behavior ('build…', 'add…', 'implement…'), even without the word 'feature'. Mines docs/roadmap.md + docs/learnings/. NOT for debugging or narrow golang-* changes.

2026-08-25

ponytail

The lazy senior dev: write the least code that works — the ponytail ladder (does it need to exist? already here? stdlib? native? existing dep? one line?), root cause over symptom, deletion over addition, `ponytail:` comments for shortcuts. whip's default posture; /ponytail on a diff or review.

2026-08-25

golang-benchmark

Golang benchmarking, profiling, and performance measurement. Use when writing or comparing Go benchmarks, profiling with pprof, interpreting CPU/memory/trace profiles, benchstat analysis, CI benchmark regression detection, or production performance issues. For optimizations → `golang-performance`.

2026-08-24

Ver todas deste repositório

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

Go Concurrency Best Practices

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

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"]

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"]

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

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

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`	Waiting for simple goroutines	Go 1.25+: prefer `wg.Go(func(){ ... })` for fire-and-wait tasks that do not panic and do not need error propagation. For Go <1.25 use `Add`/`Done`. For errors/cancellation/limits, use `errgroup` with context.
`x/sync/singleflight`	Deduplicate concurrent calls	Cache stampede prevention
`x/sync/errgroup`	Goroutine group + errors	`SetLimit(n)` replaces hand-rolled worker pools

golang-concurrency

Opções de instalação

Revise os arquivos de origem

Go Concurrency Best Practices

Core Principles

Go Concurrency Best Practices

Core Principles

Channel vs Mutex vs Atomic

WaitGroup vs errgroup

Sync Primitives Quick Reference

Concurrency Checklist

Pipelines and Worker Pools

Parallelizing Concurrency Audits

Common Mistakes

Cross-References

Go 1.26 experimental goroutine leak profile

References

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

golang-concurrency

Informações da origem

Opções de instalação

Revise os arquivos de origem

Mais deste repositório

Mais deste repositório

Go Concurrency Best Practices

Core Principles

Go Concurrency Best Practices

Core Principles

Channel vs Mutex vs Atomic

WaitGroup vs errgroup

Sync Primitives Quick Reference

Concurrency Checklist

Pipelines and Worker Pools

Parallelizing Concurrency Audits

Common Mistakes

Cross-References

Go 1.26 experimental goroutine leak profile

References