From golang-skills
Guides context.Context usage in Go: first param in signatures, avoid storing in structs or custom types, values vs parameters, cancellation, timeouts, request-scoped data.
npx claudepluginhub cxuu/golang-skills --plugin golang-skillsThis skill uses the workspace's default tool permissions.
Functions that use a Context should accept it as their **first parameter**:
Guides idiomatic context.Context usage in Go: creation, propagation, cancellation, timeouts, deadlines, values, and cross-service tracing. For Go code handling contexts.
Reviews correct Go context.Context usage: propagation, cancellation, timeouts, deadlines, values, and anti-patterns like storing in structs or passing nil. Use for context issues.
Provides code examples for Go goroutines, channels (unbuffered, buffered, directional, closing), select statements, and sync patterns when writing concurrent Go code.
Share bugs, ideas, or general feedback.
Functions that use a Context should accept it as their first parameter:
func F(ctx context.Context, /* other arguments */) error
func ProcessRequest(ctx context.Context, req *Request) (*Response, error)
This is a strong convention in Go that makes context flow visible and consistent across codebases.
Do not add a Context member to a struct type. Instead, pass ctx as a parameter
to each method that needs it:
// Bad: Context stored in struct
type Worker struct {
ctx context.Context // Don't do this
}
// Good: Context passed to methods
type Worker struct{ /* ... */ }
func (w *Worker) Process(ctx context.Context) error {
// Context explicitly passed — lifetime clear
}
Exception: Methods whose signature must match an interface in the standard library or a third-party library may need to work around this.
Do not create custom Context types or use interfaces other than context.Context
in function signatures:
// Bad: Custom context type
type MyContext interface {
context.Context
GetUserID() string
}
// Good: Use standard context.Context with value extraction
func Process(ctx context.Context) error {
userID := GetUserID(ctx)
}
Consider these options in order of preference:
Context values are appropriate for:
Context values are not appropriate for:
Read references/PATTERNS.md when deriving contexts (WithTimeout, WithCancel, WithDeadline), checking cancellation in loops or HTTP handlers, using context values with typed keys, or needing the quick reference table.
Always defer cancel() immediately after creating a derived context:
ctx, cancel := context.WithTimeout(ctx, 5*time.Second)
defer cancel()
select {
case <-ctx.Done():
return ctx.Err()
default:
// Do work
}
Contexts are immutable — it's safe to pass the same ctx to multiple
concurrent calls that share the same deadline and cancellation signal.
ctx.Err() cancellation errors