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).
87
93%
Does it follow best practices?
Impact
67%
0.98xAverage score across 3 eval scenarios
Passed
No findings from the security scan
Go library code organization
Constants before types
100%
100%
Types before constructor
100%
100%
Constructor before methods
100%
100%
Helpers last
70%
50%
One type per file
100%
100%
No blank imports in library
100%
100%
No dot imports
100%
100%
Validation helper unexported
100%
100%
Internal helpers unexported
100%
100%
Go error formatting, if-init scoping, and generics over any
%q in region error
100%
100%
%q in environment error
100%
100%
%q in log-level error
100%
100%
if-init scoping
0%
0%
Generic Contains signature
100%
100%
Generic Filter signature
100%
100%
Naked return in short helper
0%
0%
Named returns in long function
0%
0%
No any in utility functions
100%
100%
No pre-declared err before if
100%
100%
Idiomatic Go 1.22+ iteration patterns in a leaderboard package
range-n for counting
0%
0%
range-value iteration
100%
100%
slices package for sorting
0%
0%
slices.Contains for membership
0%
0%
lo for filter
0%
0%
lo for group-by
0%
0%
no speculative preallocation
100%
100%
slices initialized not nil
25%
25%
go.mod targets Go 1.22+
100%
100%
tests present and pass
100%
100%
4158351
Table of Contents
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.