Golang code style, formatting and conventions. Use when writing Go code, reviewing style, configuring linters, writing comments, or establishing project standards.
This skill defines Go (Golang) coding style conventions focused on readability, clarity, and maintainable code structure. It addresses the problem of inconsistent code patterns across teams and AI-generated code, where different formatting or structural decisions can reduce readability and increase cognitive load during reviews. Instead of focusing on mechanical formatting (typically handled by tools like linters and gofmt), it establishes higher-level guidance for how Go code should be written to remain clear and idiomatic. The core principle is prioritizing explicit, intention-revealing code over clever or compact constructs.
Key capabilities include guidance on line breaking rules for long expressions, requiring semantic breaks and multi-line formatting for function calls with multiple arguments, as well as recommending design adjustments like option structs when signatures grow too large. It also defines variable declaration semantics, distinguishing between zero-value initialization using 'var' and intentional initialization using ':='. It enforces explicit initialization of slices and maps to avoid nil-related runtime issues and JSON surprises. Composite literals must use named fields to preserve forward compatibility. Control flow guidance emphasizes early returns to reduce nesting and discourages unnecessary 'else' blocks. It also encourages default-then-override patterns for clarity, along with consistent commenting when rules are intentionally ignored.
This skill is intended for Go developers, technical teams, and AI coding agents that generate or review Go code. It is particularly useful in code review workflows, backend service development, and projects requiring consistent engineering standards across multiple contributors. It helps maintain readability in large codebases, reduces common pitfalls in Go such as nil maps or overly complex function signatures, and supports establishing shared conventions in engineering organizations. It is designed to complement other Go-focused skills such as naming, design patterns, and struct/interface design guidance.
'var' is preferred when you want to explicitly initialize a variable to its zero value, signaling that it will be assigned later or intentionally starts empty. ':=' is used when assigning a meaningful non-zero value at declaration time. This distinction helps communicate intent clearly.
No. Linters and formatting tools handle mechanical concerns like syntax formatting. This skill focuses on higher-level readability decisions, such as structure, clarity, naming intent, and control flow patterns.
Lines longer than roughly 120 characters should be broken at semantic boundaries. For function calls with multiple arguments, each argument should be placed on its own line. If a function signature becomes too large, refactoring into an options structure is preferred over excessive wrapping.
Yes, but any deviation should be explicitly documented with a comment in the code explaining why the rule is being ignored to preserve clarity for future readers.
Quick Setup:
.claude/skills/Repository
samber/cc-skills-golang