go-contextlisted

Use when designing, propagating, or debugging context.Context flow in Go — first-parameter placement, deadlines and cancellation, request-scoped values, WithoutCancel for fire-and-forget work, and key-collision-safe value patterns. Apply proactively whenever a function takes ctx, spawns work, or accepts request-scoped data, even if the user has not asked about context.
muratmirgun/gophers · ★ 5 · Data & Documents · score 83

Install: claude install-skill muratmirgun/gophers

# Go Context Usage `context.Context` carries the cancellation, deadline, and request-scoped values for a single unit of work. Pass it explicitly through the entire call chain — never store it, never replace it with `Background()` mid-flight, never use it as a side-channel for ordinary parameters. ## Core Rules 1. **`ctx` is the first parameter**, named `ctx context.Context`. No exceptions outside interface stubs imposed by external APIs. 2. **Propagate the caller's `ctx`** all the way down. Do not start a new tree with `context.Background()` inside a request path. 3. **Do not store `Context` in a struct**. Pass it to each method that needs it. 4. **Always `defer cancel()`** after `WithCancel`/`WithTimeout`/`WithDeadline`, unless ownership is explicitly transferred. 5. **Context values are for request-scoped metadata only** (request ID, auth principal, trace). Never for optional function parameters or config. 6. **Value keys must be unexported named types** to prevent cross-package collisions. ## Where Does Data Belong? Pick the most explicit option that fits — context values are the last resort. | Option | Use for | Why | |---|---|---| | Function parameter | Anything the function *needs* to do its job | Type-checked, visible at call site | | Method receiver | State that belongs to the type | Already in scope | | Package-level config | Process-wide, immutable | One owner, no hidden flow | | `context.Value` | Request-scoped metadata that crosses layers without being a fun