Go (Golang) naming conventions — covers packages, constructors, structs, interfaces, constants, enums, errors, booleans, receivers, getters/setters, functional options, acronyms, test functions, and subtest names. Use this skill when writing new Go code, reviewing or refactoring, choosing between naming alternatives (New vs NewTypeName, isConnected vs connected, ErrNotFound vs NotFoundError, StatusReady vs StatusUnknown at iota 0), debating Go package names (utils/helpers anti-patterns), or asking about Go naming best practices. Also trigger when the user mentions MixedCaps vs snake_case, ALL_CAPS constants, Get-prefix on getters, or error string casing. Do NOT use for general Go implementation questions that don't involve naming decisions.
89
88%
Does it follow best practices?
Impact
90%
1.34xAverage score across 3 eval scenarios
Passed
No known issues
Functional options pattern naming
Options struct name
0%
0%
Option function type singular
100%
100%
With* option functions
100%
100%
Default options factory
0%
100%
Constants MixedCaps not ALL_CAPS
100%
100%
Constants by role not value
100%
100%
No Struct/Object/Data suffix
100%
100%
No stuttering in option types
100%
100%
Constructor uses New or NewTypeName
0%
100%
Functional options used for 3+ params
100%
100%
Test naming conventions
input field name
0%
0%
expected field prefix
0%
100%
Subtest names fully lowercase
83%
100%
Subtest acronyms lowercase
0%
100%
Test helper must prefix
100%
100%
Test function naming pattern
50%
100%
Subcase underscore separator
0%
100%
Table test struct has name field
100%
100%
No exported test helpers
100%
100%
File naming and function naming
File names lowercase
100%
100%
File names use underscores
100%
100%
Value-returning functions are nouns
33%
50%
Action functions are verbs
100%
100%
Ambiguous params have descriptive names
100%
100%
No type in variable names
100%
100%
No package stutter in functions
40%
100%
Test file naming
100%
100%
Descriptive short params for clear types
100%
100%
e9761db
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.