From golang-dev
This skill helps name Go identifiers (packages, functions, methods, types, variables, constants, receivers) following Go team conventions and industry best practices. Triggers on user requests like "name this function", "what should I call this", "help me name this variable/type/package", "review these names", or "suggest a better name". Also triggers proactively when the agent creates new Go code elements (functions, types, variables, packages, methods, constants), when reviewing or refactoring existing names for Go idiomaticity, when creating new Go files or packages, or when names appear unclear or violate Go conventions.
npx claudepluginhub notorious-ai/claude-plugins --plugin golang-devThis skill uses the workspace's default tool permissions.
Name Go identifiers following Go team conventions - for packages, functions, methods, types, variables, constants, and receivers.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Searches prompts.chat for AI prompt templates by keyword or category, retrieves by ID with variable handling, and improves prompts via AI. Use for discovering or enhancing prompts.
Guides MCP server integration in Claude Code plugins via .mcp.json or plugin.json configs for stdio, SSE, HTTP types, enabling external services as tools.
Name Go identifiers following Go team conventions - for packages, functions, methods, types, variables, constants, and receivers.
Names are the primary documentation readers encounter. Follow these rules for every identifier:
When naming a Go identifier:
Classify what you're naming to load appropriate guidance:
| Identifier Type | Examples | Load Reference |
|---|---|---|
| Functions/Methods | Public/private functions, methods | references/functions-and-methods.md |
| Packages/Types | Package names, structs, interfaces | references/packages-and-types.md |
| Variables/Constants | Local vars, parameters, constants | references/variables-and-constants.md |
| Test doubles | Stubs, fakes, mocks, test helpers | references/test-doubles.md |
Before choosing a name, understand the context where it will be read:
Package name: Visible at every call site (pkg.Function)
Type name: Visible at declaration and usage
Function name: Read with package prefix (pkg.DoThing)
Method name: Read with receiver type (receiver.Method)
Variable name: Read within scope (usually local)
Key question: What information is already visible to the reader?
For all identifiers:
Quick reference:
| Category | Format | Example |
|---|---|---|
| Packages | lowercase, no underscores | encoding, httputil |
| Exported functions | MixedCaps, noun or verb phrase | Marshal, WriteTo |
| Unexported functions | mixedCaps | parseHeader, readAll |
| Types | MixedCaps, singular noun | Reader, ResponseWriter |
| Variables | mixedCaps, scope-proportional | count, c, userID |
| Constants | MixedCaps (not SCREAMING_CASE) | MaxRetries, defaultTimeout |
| Receivers | 1-2 letters, type abbreviation | c *Config, rw *ResponseWriter |
Repetition:
// Bad: package name + exported name repeat
package yaml
func ParseYAML(input string) // yaml.ParseYAML()
// Good: package provides context
package yaml
func Parse(input string) // yaml.Parse()
Unnecessary words:
// Bad: type visible from usage
var nameString string
var usersList []User
// Good: type clear from context
var name string
var users []User
Get prefix:
// Bad: unnecessary Get prefix
func (c *Config) GetJobName() string
// Good: noun-like name for accessor
func (c *Config) JobName() string
When functions differ only by type:
// Good: type suffix for disambiguation
func ParseInt(s string) (int, error)
func ParseInt64(s string) (int64, error)
func AppendInt(buf []byte, i int) []byte
func AppendInt64(buf []byte, i int64) []byte
When variable appears in multiple forms:
// Good: clarify with representation
limitStr := r.FormValue("limit")
limit, err := strconv.Atoi(limitStr)
// Also good: clarify with raw/parsed
limitRaw := r.FormValue("limit")
limit, err := strconv.Atoi(limitRaw)
When scope has similar concepts:
// Good: disambiguate with context
userCount := countUsers()
projectCount := countProjects()
Name length should reflect scope size:
| Scope Size | Line Count | Name Length Guidance |
|---|---|---|
| Small | 1-7 lines | Single letter often sufficient (i, c, n) |
| Medium | 8-15 lines | Single word (count, user, config) |
| Large | 16-25 lines | Descriptive phrase (userCount, activeUsers) |
| Very Large | 25+ lines | Full context (httpServerConfig, maxRetryAttempts) |
Exceptions:
db, ctx, id)buffer not b in large scope)Before finalizing, check:
Before committing to a name:
Context awareness:
Format:
Clarity:
Special rules:
Load these as needed based on identifier type:
| File | Contains | Load When |
|---|---|---|
references/functions-and-methods.md | Function/method naming rules, verb selection, repetition avoidance | Naming functions or methods |
references/packages-and-types.md | Package naming, type naming, struct naming, initialisms | Naming packages, types, interfaces, structs |
references/variables-and-constants.md | Variable scope rules, constant naming, single-letter usage, receivers | Naming variables, parameters, constants, receivers |
references/test-doubles.md | Test package naming, stub/fake/spy naming, local test variables | Creating test helpers or doubles |
| File | Contains |
|---|---|
examples/stdlib-examples.md | Good naming examples from Go standard library |
examples/anti-patterns.md | Common naming mistakes with corrections |
When to load examples:
Straightforward naming - Skip examples. The workflow above and reference files provide sufficient guidance.
Ambiguous or unfamiliar patterns - Search examples for similar cases:
# Search for similar naming patterns
grep -i "keyword" examples/stdlib-examples.md
Learning Go naming conventions - Load examples in full to understand Go team patterns and idioms.
XML tags for selective searching:
| Tag | Purpose | Context |
|---|---|---|
<example> | Full example with context and explanation | Detailed learning |
<good> | Correct naming pattern | Best practices |
<bad> | Incorrect naming pattern | Anti-patterns |
<better> | Improved alternative | Refactoring guidance |
Test, benchmark, and example functions in _test.go files may include underscores:
// Good: underscores for readability in test names
func TestConfig_Load_WithInvalidPath(t *testing.T)
func BenchmarkHTTPServer_HandleRequest(b *testing.B)
Only generated or third-party packages may have underscores. When importing:
// Must rename at import
import foopb "path/to/foo_go_proto"
Generated test packages use underscores:
// Good: black box tests
package linkedlist_test
// Good: integration tests
package linked_list_service_test
Use single letters sparingly and only when meaning is obvious:
// Good: common conventions
r for io.Reader or *http.Request
w for io.Writer or http.ResponseWriter
i, j, k for loop indices
x, y for coordinates
c for counters in very small scope
Stomping (reusing variable in same scope):
// Good: original value no longer needed
ctx, cancel := context.WithTimeout(ctx, 3*time.Second)
defer cancel()
Shadowing (new variable in nested scope):
// Bad: shadows outer ctx
if condition {
ctx, cancel := context.WithTimeout(ctx, time.Second)
defer cancel()
// ...
}
// ctx here is still the original - BUG!
// Good: use assignment, not declaration
if condition {
var cancel func()
ctx, cancel = context.WithTimeout(ctx, time.Second)
defer cancel()
// ...
}
Avoid util, helper, common as sole package names. These are uninformative and tempt import renaming.
// Bad: unclear at call site
db := test.NewDatabaseFromFile(...)
// Good: clear what package provides
db := spannertest.NewDatabaseFromFile(...)
Use AskUserQuestion when:
Multiple valid approaches exist - Present options for user to choose:
userConfig or config given the scope?Handler vs Processor vs Manager?auth or authz or security?Codebase has conflicting conventions - Let user decide:
Get prefix and direct nouns - which to follow?helper package name or refactor?Domain-specific terminology - User knows domain better:
Do not guess - ask when the name choice significantly affects code clarity or consistency.