Install any skill in seconds. Free to start, no credit card required.
Get Started Free →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.
| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-01 | ✓→✗ | ▼ Worse | 6% | 0% |
| case-09 | ✓→✓ | = Same ✓ | 3% | 0% |
| case-02 | ✓→✓ | = Same ✓ | 57% | 0% |
| case-03 | ✓→✓ | = Same ✓ | 7% | 0% |
| case-04 | ✓→✓ | = Same ✓ | 62% | 0% |
> Community default. A company skill that explicitly supersedes samber/cc-skills-golang@golang-context skill takes precedence.
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.
ctx MUST be the first parameter, named ctx context.Contextnil context — use context.TODO() if unsurecancel() MUST be called on all control-flow paths for WithCancel/WithTimeout/WithDeadline, unless ownership of the context and cancel function is explicitly returned or transferredcontext.Background() MUST only be used at the top level (main, init, tests)context.TODO() as a placeholder when you know a context is needed but don't have one yetcontext.Background() in the middle of a request pathcontext.WithoutCancel (Go 1.21+) when spawning background work that must outlive the parent request| 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 | context.WithTimeout(parentCtx, duration) |
The most important rule: propagate the same context through the entire call chain. When you propagate correctly, cancelling the parent context cancels all downstream work automatically.
go// ✗ Bad — creates a new context, breaking the chain func (s *OrderService) Create(ctx context.Context, order Order) error { return s.db.ExecContext(context.Background(), "INSERT INTO orders ...", order.ID) } // ✓ Good — propagates the caller's context func (s *OrderService) Create(ctx context.Context, order Order) error { return s.db.ExecContext(ctx, "INSERT INTO orders ...", order.ID) }
WithCancel for manual cancellation, WithTimeout for automatic cancellation after a duration, WithDeadline for absolute time deadlines. Patterns for listening (<-ctx.Done()) in concurrent code, AfterFunc callbacks, and WithoutCancel for operations that must outlive their parent request (e.g., audit logs).r.Context() for request-scoped cancellation, middleware integration, and propagating to services. HTTP client patterns: NewRequestWithContext, client timeouts, and retries with context awareness. Database operations: always use *Context variants (QueryContext, ExecContext) to respect deadlines.samber/cc-skills-golang@golang-concurrency skill for goroutine cancellation patterns using contextsamber/cc-skills-golang@golang-database skill for context-aware database operations (QueryContext, ExecContext)samber/cc-skills-golang@golang-observability skill for trace context propagation with OpenTelemetrysamber/cc-skills-golang@golang-design-patterns skill for timeout and resilience patternsMany context pitfalls are caught automatically by linters: govet, staticcheck. → See the samber/cc-skills-golang@golang-lint skill for configuration and usage.
Other measured skills in the registry, with their headline benchmark lift.