From golang-skills
Guides declaration and initialization of Go variables, constants, structs, and maps. Covers var vs :=, if-init scope, iota enums, composite literal formatting, and struct design.
How this skill is triggered — by the user, by Claude, or both
Slash command
/golang-skills:go-declarationsThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
> Compatibility: Examples may use `any`, which requires Go 1.18+.
Compatibility: Examples may use
any, which requires Go 1.18+.
references/SCOPE.md - Read when deciding between var, :=, if-init, and narrow variable scope.references/IOTA.md - Read when designing constants or enum-like values.references/INITIALIZATION.md - Read when initializing structs, maps, zero values, or pointers.references/LITERALS.md - Read for composite literal formatting and keyed-field tradeoffs.references/STRUCTS.md - Read when designing or initializing structs.references/SHADOWING.md - Read when a declaration may shadow a builtin or outer variable.| Context | Use | Example |
|---|---|---|
| Top-level | var (always) | var _s = F() |
| Local with value | := | s := "foo" |
| Local zero-value (intentional) | var | var filtered []int |
| Type differs from expression | var with type | var _e error = F() |
Group related var, const, type in parenthesized blocks. Separate
unrelated declarations into distinct blocks.
// Bad
const a = 1
const b = 2
// Good
const (
a = 1
b = 2
)
Inside functions, group adjacent vars even if unrelated:
var (
caller = c.name
format = "json"
timeout = 5 * time.Second
)
Start enums at one so the zero value represents invalid/unset:
const (
Add Operation = iota + 1
Subtract
Multiply
)
Use zero when the default behavior is desirable (e.g., LogToStdout).
Use if-init to limit scope when the result is only needed for the error check:
if err := os.WriteFile(name, data, 0644); err != nil {
return err
}
Don't reduce scope if it forces deeper nesting or you need the result outside
the if. Move constants into functions when only used there.
go vet). Exception: test tables
with ≤3 fields.var for zero-value structs: var user User not user := User{}&T{} over new(T): sptr := &T{Name: "bar"}Use field names for external package types. Match closing brace indentation
with the opening line. Omit repeated type names in slice/map literals
(gofmt -s).
| Scenario | Use | Example |
|---|---|---|
| Empty, populated later | make(map[K]V) | m := make(map[string]int) |
| Nil declaration | var | var m map[string]int |
| Fixed entries at init | Literal | m := map[string]int{"a": 1} |
make() visually distinguishes empty-but-initialized from nil. Use size hints
when the count is known.
Use backtick strings to avoid hand-escaped characters:
// Bad
wantError := "unknown name:\"test\""
// Good
wantError := `unknown name:"test"`
Ideal for regex, SQL, JSON, and multi-line text.
any Over interface{}Go 1.18+: use any instead of interface{} in all new code.
Never use predeclared identifiers (error, string, len, cap, append,
copy, new, make, close, delete, panic, recover, any, true,
false, nil, iota) as names. Use go vet to detect.
// Bad — shadows the builtin
var error string
// Good
var errorMessage string
new and make, or initializing slices and maps:= redeclaration, or avoiding variable shadowing2plugins reuse this skill
First indexed Jun 20, 2026
npx claudepluginhub cxuu/golang-skills --plugin golang-skillsGuides Go code style conventions: line length and breaking, variable declarations, control flow clarity, and when comments help or hurt. Use when writing or reviewing Go code.
Go coding standards and style conventions grounded in Effective Go, Go Code Review Comments, and production-proven idioms. Use when writing or reviewing Go code, enforcing naming conventions, import ordering, variable declarations, struct initialization, or formatting rules. Trigger examples: "check Go style", "fix formatting", "review naming", "Go conventions". Do NOT use for architecture decisions, concurrency patterns, or performance tuning — use go-architecture-review, go-concurrency-review, or go-performance-review instead.
Go language conventions, idioms, and toolchain. Invoke when task involves any interaction with Go code — writing, reviewing, refactoring, debugging, or understanding Go projects.