Golang code style conventions — line length and breaking, variable declarations, control flow clarity, when comments help vs hurt. Use when writing or reviewing Go code, asking about style or clarity, or establishing project coding standards. Not for naming conventions (→ See `samber/cc-skills-golang@golang-naming` skill), linter configuration (→ See `samber/cc-skills-golang@golang-lint` skill), or doc comments (→ See `samber/cc-skills-golang@golang-documentation` skill).
95
100%
Does it follow best practices?
Impact
87%
0.97xAverage score across 3 eval scenarios
Passed
No known issues
Library package organization and import discipline
No blank import in library
100%
100%
Blank import in main
100%
100%
No dot imports
100%
100%
Image type in own file
100%
100%
Metadata type in own file
100%
100%
File order: constants before types
100%
100%
File order: constructor before methods
100%
100%
Unexported internal fields
100%
100%
%q in error messages
100%
100%
Unexported helpers
100%
100%
Iterative patterns, error formatting, variable scoping
range over index loop
100%
100%
range n for counting
0%
50%
%q in parse errors
100%
100%
if-init scope for errors
100%
0%
No naked return in long funcs
100%
100%
Early return on parse error
100%
100%
Unexported helpers
100%
100%
Map initialized not nil
100%
100%
strings.Builder for report
100%
100%
strconv not fmt for int conversion
0%
0%
Modern Go collection utilities with slices, maps, lo, generics
slices package for sorting
100%
100%
lo for filter operation
100%
100%
lo for group-by operation
100%
100%
lo for chunk/paginate
100%
100%
Generics not any
100%
100%
maps package usage
0%
0%
No reflect usage
100%
100%
Initialized empty collections
100%
100%
SortByPrice non-mutating
100%
100%
Capacity hint on output slice
0%
0%
8c7e016
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.