From golang-skills
Guides Go declarations and initialization: var vs :=, grouping vars/consts, iota enums, if-init scoping, struct field-named init, composite literal formatting.
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
---
| 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() |
Read references/SCOPE.md when deciding between var and := in complex initialization patterns or multi-return assignments.
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).
Read references/IOTA.md when designing iota enums with bitmask patterns, byte-size constants, or String() methods.
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.
Read references/SCOPE.md when working with top-level declarations or choosing between var and := for local variables.
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"}Read references/STRUCTS.md when initializing structs with many fields, building slices of struct pointers, or choosing single-line vs multi-line format.
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).
Read references/INITIALIZATION.md when working with complex composite literals, cuddled braces, or zero-value field decisions.
Read references/LITERALS.md when formatting complex composite literals.
| 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
Read references/SHADOWING.md when debugging issues where := creates new variables that shadow outer scope.
new and make, or initializing slices and maps:= redeclaration, or avoiding variable shadowingnpx claudepluginhub cxuu/golang-skills --plugin golang-skillsDirects Go code style decisions: line breaks at semantic boundaries, zero-value variable declarations, explicit slice/map initialization, and control flow clarity.
Guides Go control flow best practices: if with init, guard clauses/early returns, for/range loops, switches/type switches, blank identifier, redeclaration/shadowing rules.
Go language conventions, idioms, and toolchain. Invoke when task involves any interaction with Go code — writing, reviewing, refactoring, debugging, or understanding Go projects.