cxuu/golang-skills▌

Systematic Go code review against community style standards and best practices. \n \n Covers 15+ review categories: formatting, documentation, error handling, naming, concurrency, interfaces, data structures, security, declarations, functions, style, logging, imports, generics, and testing \n Includes automated pre-review checks via gofmt , go vet , and golangci-lint to catch mechanical issues before manual review \n Organizes findings by severity (must-fix, should-fix, nit) using a consistent t

When this skill does NOT apply: For concurrent access to data structures (mutexes, atomic operations), see go-concurrency. For defensive copying at API boundaries, see go-defensive. For pre-sizing capacity for performance, see go-performance.

Functions that use a Context should accept it as their first parameter:

When this skill does NOT apply: For naming individual identifiers within a package, see go-naming. For organizing functions within a single file, see go-functions. For configuring linters that enforce import rules, see go-linting.

Functional options is a pattern where you declare an opaque Option type that records information in an internal struct. The constructor accepts a variadic number of these options and applies them to configure the result.

Read references/SWITCH-PATTERNS.md when using switch statements, type switches, or break with labels

When hardening code at API boundaries, check in this order:

In Go, errors are values — they are created by code and consumed by code.

Performance-specific guidelines apply only to the hot path. Don't prematurely optimize—focus these patterns where they matter most.

Normative: When you spawn goroutines, make it clear when or whether they exit.

Names should:

Normative: Test failures must be diagnosable without reading the test source.

More important than any "blessed" set of linters: lint consistently across a codebase.

When writing readable Go code, apply these principles in order of importance:

See assets/doc-template.go when writing doc comments for a new package or exported type and need a complete reference of all documentation conventions.

Interfaces belong in the package that consumes values, not the package that implements them. Return concrete (usually pointer or struct) types from constructors so new methods can be added without refactoring.