Idiomatic context.Context usage in Golang — propagation through API boundaries, cancellation, timeouts and deadlines, request-scoped values,…
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
don't have the plugin yet? install it then click "run inline in claude" again.