| name | golang-context |
| description | Idiomatic context.Context usage in Golang — propagation through API boundaries, cancellation, timeouts and deadlines, request-scoped values, context.WithoutCancel for background work outliving requests. Apply when designing context propagation across layers, debugging leaked or unexpired contexts, choosing between context.Background/TODO/WithoutCancel, or storing values in context. Not for code that merely accepts ctx as first parameter. |
| user-invocable | true |
| license | MIT |
| compatibility | Designed for Claude Code or similar AI coding agents, and for projects using Golang. |
| metadata | {"author":"samber","version":"1.2.1","openclaw":{"emoji":"🔗","homepage":"https://github.com/samber/cc-skills-golang","requires":{"bins":["go"]},"install":[]}} |
| allowed-tools | Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent |
Community default. A company skill that explicitly supersedes samber/cc-skills-golang@golang-context skill takes precedence.
Go context.Context Best Practices
context.Context is Go's mechanism for propagating cancellation signals, deadlines, and request-scoped values across API boundaries and between goroutines. Think of it as the "session" of a request — it ties together every operation that belongs to the same unit of work.
Best Practices Summary
- The same context MUST be propagated through the entire request lifecycle: HTTP handler → service → DB → external APIs
ctx MUST be the first parameter, named ctx context.Context
- NEVER store context in a struct — pass explicitly through function parameters
- NEVER pass
nil context — use context.TODO() if unsure
cancel() MUST be called on all control-flow paths for WithCancel/WithTimeout/WithDeadline, unless ownership of the context and cancel function is explicitly returned or transferred
context.Background() MUST only be used at the top level (main, init, tests)
- Use
context.TODO() as a placeholder when you know a context is needed but don't have one yet
- NEVER create a new
context.Background() in the middle of a request path
- Context value keys MUST be unexported types to prevent collisions
- Context values MUST only carry request-scoped metadata — NEVER function parameters
- Use
context.WithoutCancel (Go 1.21+) when spawning background work that must outlive the parent request
Creating Contexts
| Situation | Use |
|---|
| Entry point (main, init, test) | context.Background() |
| Function needs context but caller doesn't provide one yet | context.TODO() |
| Inside an HTTP handler | r.Context() |
| Need cancellation control | context.WithCancel(parentCtx) |
| Need a deadline/timeout | |