Back to list
jovermier

go-concurrency

by jovermier

Claude Code agents for Go, GraphQL, Next.js, and Playwright. 4 agents, 12 skills for code review and test generation.

0🍴 0📅 Jan 3, 2026

SKILL.md


name: go-concurrency description: Go concurrency patterns including goroutines, channels, context propagation, and sync primitives. Use when working with goroutines, channels, context.Context, or any concurrent Go code.

Go Concurrency

Expert guidance for writing safe, leak-free concurrent Go code.

Quick Reference

PatternWhen to UseKey Points
Goroutine + selectLong-running workersAlways have exit condition
context.WithCancelCancellable operationsdefer cancel()
context.WithTimeoutTime-bound operationsCheck ctx.Done()
sync.MutexMutual exclusionLock/defer Unlock
sync.RWMutexRead-heavy lockingSeparate RLock/RUnlock
sync.WaitGroupWait for goroutinesAdd before, Done after
errgroup.GroupGoroutines with errorsWait collects first error
channelSignaling/streamingClose sender side

What Do You Need?

  1. Goroutine lifecycle - Starting, stopping, leaking prevention
  2. Channel usage - Buffered vs unbuffered, closing patterns
  3. Context propagation - Passing context through call stack
  4. Sync primitives - Mutex, RWMutex, WaitGroup, Once
  5. Error handling - errgroup for concurrent errors

Specify a number or describe your concurrent Go code.

Routing

ResponseReference to Read
1, "goroutine", "worker", "job"goroutines.md
2, "channel", "buffer", "send", "receive"channels.md
3, "context", "cancel", "timeout", "deadline"context.md
4, "mutex", "lock", "race", "sync"sync.md
5, general concurrencyRead all references based on code

Critical Rules

  • Goroutines must exit: Every goroutine needs a known exit path
  • No goroutine leaks: Always have a way to signal shutdown
  • Context goes first: context.Context should be the first parameter
  • Defer cancel(): Always defer cancel() when using WithCancel/Timeout
  • Channel ownership: Only the sender should close a channel
  • Avoid buffered channels as mutexes: Use sync.Mutex instead

Common Pitfalls

PitfallSeverityFix
Goroutine that never exitsCriticalAdd ctx.Done() select case
Missing defer cancel()HighAlways defer after WithCancel/Timeout
Using buffered channel as mutexHighUse sync.Mutex
Not propagating contextHighAdd ctx parameter throughout call stack
Race conditionsCriticalUse proper sync or eliminate shared state
Unbounded goroutine creationHighUse worker pool pattern
Reading from closed channelMediumAlways check ok value from range

Reference Index

FileTopics
goroutines.mdLifecycle patterns, worker pools, leak prevention
channels.mdBuffered vs unbuffered, closing patterns, select
context.mdPropagation, cancellation, timeouts, deadlines
sync.mdMutex, RWMutex, WaitGroup, Once, Pool

Success Criteria

Code is concurrency-safe when:

  • All goroutines have exit conditions
  • Context is propagated through the call stack
  • No race conditions (go test -race passes)
  • Resources are cleaned up (defer cancel(), defer wg.Done())
  • Channels are closed by sender only
  • No buffered-channel-as-mutex patterns

Score

Total Score

65/100

Based on repository quality metrics

SKILL.md

SKILL.mdファイルが含まれている

+20
LICENSE

ライセンスが設定されている

+10
説明文

100文字以上の説明がある

+10
人気

GitHub Stars 100以上

0/15
最近の活動

3ヶ月以内に更新がある

0/10
フォーク

10回以上フォークされている

0/5
Issue管理

オープンIssueが50未満

+5
言語

プログラミング言語が設定されている

0/5
タグ

1つ以上のタグが設定されている

0/5

Reviews

💬

Reviews coming soon