
Golang Patterns
Install this when you want an agent to write, refactor, or review Go code using idiomatic patterns instead of clever one-offs.
Overview
Golang-patterns is an agent skill most often used in Build (also Ship review) that teaches idiomatic Go patterns for writing, refactoring, and reviewing maintainable backend and CLI code.
Install
npx skills add https://github.com/affaan-m/everything-claude-code --skill golang-patternsWhat is this skill?
- Activates when writing new Go, reviewing Go, refactoring, or designing packages and modules
- Core principles: simplicity over cleverness, useful zero values, and explicit error handling with fmt.Errorf wrapping
- Contrast tables of good vs bad patterns for readability and maintainability
- Covers concurrency-friendly structs (e.g. mutex-backed counters) and standard-library idioms like bytes.Buffer
- Origin ECC: opinionated conventions aligned with robust, efficient, maintainable Go applications
Adoption & trust: 9k installs on skills.sh; 210k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your agent produces Go that compiles but feels non-idiomatic, overly clever, or hard to extend across packages.
Who is it for?
Solo builders actively implementing or reviewing Go backends, workers, or CLIs who want consistent idiomatic guidance in the agent loop.
Skip if: Teams that only need a one-off script in another language, or repos where Go style is already fully enforced by custom arch docs the agent must follow instead.
When should I use this skill?
Writing new Go code, reviewing Go code, refactoring existing Go code, or designing Go packages/modules.
What do I get? / Deliverables
After running the skill, generated or revised Go follows clarity-first conventions, explicit errors, and package shapes that are easier to review and maintain.
- Idiomatic Go implementations or refactors
- Review feedback aligned to documented good vs bad examples
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Go services and CLIs are built in the Build phase; this skill is shelved under backend because most applied patterns target packages, APIs, and concurrent server code. Backend subphase is the canonical home for language conventions, error wrapping, interfaces, and module design that shape how the product core is implemented.
Where it fits
Implement a new HTTP handler package with wrapped errors and small, obvious exported APIs.
Review a PR that introduced nested closures in Go and rewrite toward direct, readable control flow.
Refactor a third-party SDK wrapper module for clearer interfaces and testable seams.
How it compares
Use as a language-style playbook layered on top of generic code-review skills, not as a substitute for gofmt, vet, or project-specific architecture RFCs.
Common Questions / FAQ
Who is golang-patterns for?
Solo and indie builders using AI coding agents on Go APIs, CLIs, and backend services who want idiomatic structure without re-explaining Go conventions every session.
When should I use golang-patterns?
Use it in Build while writing or refactoring packages, and in Ship during review when diffs need a Go-idiom pass; also when designing module boundaries before larger features land.
Is golang-patterns safe to install?
It is procedural documentation-style guidance with no built-in network or shell requirements in the skill body; review the Security Audits panel on this Prism page before trusting any third-party skill in production workflows.
SKILL.md
READMESKILL.md - Golang Patterns
# Go Development Patterns Idiomatic Go patterns and best practices for building robust, efficient, and maintainable applications. ## When to Activate - Writing new Go code - Reviewing Go code - Refactoring existing Go code - Designing Go packages/modules ## Core Principles ### 1. Simplicity and Clarity Go favors simplicity over cleverness. Code should be obvious and easy to read. ```go // Good: Clear and direct func GetUser(id string) (*User, error) { user, err := db.FindUser(id) if err != nil { return nil, fmt.Errorf("get user %s: %w", id, err) } return user, nil } // Bad: Overly clever func GetUser(id string) (*User, error) { return func() (*User, error) { if u, e := db.FindUser(id); e == nil { return u, nil } else { return nil, e } }() } ``` ### 2. Make the Zero Value Useful Design types so their zero value is immediately usable without initialization. ```go // Good: Zero value is useful type Counter struct { mu sync.Mutex count int // zero value is 0, ready to use } func (c *Counter) Inc() { c.mu.Lock() c.count++ c.mu.Unlock() } // Good: bytes.Buffer works with zero value var buf bytes.Buffer buf.WriteString("hello") // Bad: Requires initialization type BadCounter struct { counts map[string]int // nil map will panic } ``` ### 3. Accept Interfaces, Return Structs Functions should accept interface parameters and return concrete types. ```go // Good: Accepts interface, returns concrete type func ProcessData(r io.Reader) (*Result, error) { data, err := io.ReadAll(r) if err != nil { return nil, err } return &Result{Data: data}, nil } // Bad: Returns interface (hides implementation details unnecessarily) func ProcessData(r io.Reader) (io.Reader, error) { // ... } ``` ## Error Handling Patterns ### Error Wrapping with Context ```go // Good: Wrap errors with context func LoadConfig(path string) (*Config, error) { data, err := os.ReadFile(path) if err != nil { return nil, fmt.Errorf("load config %s: %w", path, err) } var cfg Config if err := json.Unmarshal(data, &cfg); err != nil { return nil, fmt.Errorf("parse config %s: %w", path, err) } return &cfg, nil } ``` ### Custom Error Types ```go // Define domain-specific errors type ValidationError struct { Field string Message string } func (e *ValidationError) Error() string { return fmt.Sprintf("validation failed on %s: %s", e.Field, e.Message) } // Sentinel errors for common cases var ( ErrNotFound = errors.New("resource not found") ErrUnauthorized = errors.New("unauthorized") ErrInvalidInput = errors.New("invalid input") ) ``` ### Error Checking with errors.Is and errors.As ```go func HandleError(err error) { // Check for specific error if errors.Is(err, sql.ErrNoRows) { log.Println("No records found") return } // Check for error type var validationErr *ValidationError if errors.As(err, &validationErr) { log.Printf("Validation error on field %s: %s", validationErr.Field, validationErr.Message) return } // Unknown error log.Printf("Unexpected error: %v", err) } ``` ### Never Ignore Errors ```go // Bad: Ignoring error with blank identifier result, _ := doSomething() // Good: Handle or explicitly document why it's safe to ignore result, err := doSomething() if err != nil { return err } // Acceptable: When error truly doesn't matter (rare) _ = writer.Close() // Best-effort cleanup, error logged elsewhere ``` ## Concurrency Patterns ### Worker Pool ```go func WorkerPool(jobs <-chan Job, results chan<- Result, numWorkers int) { var wg sync.WaitGroup for i := 0; i < numWorkers; i++