effective-go
Applies official Go language idioms and best practices to code reviews and new implementations.
Install
mkdir -p .claude/skills/effective-go && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/102" && unzip -o skill.zip -d .claude/skills/effective-go && rm skill.zipInstalls to .claude/skills/effective-go
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Apply Go best practices, idioms, and conventions from golang.org/doc/effective_go. Use when writing, reviewing, or refactoring Go code to ensure idiomatic, clean, and efficient implementations.Key capabilities
- →Enforce standard formatting using gofmt
- →Apply MixedCaps naming conventions for exported identifiers
- →Implement error handling by returning errors instead of panicking
- →Utilize channels for memory sharing in concurrency
- →Design interfaces with one to three methods
- →Write documentation for all exported symbols
How it works
The skill applies conventions from the official Effective Go guide to evaluate and refactor code. It mandates specific formatting, naming, and structural patterns defined in the language documentation.
Inputs & outputs
When to use effective-go
- →Refactoring Go code for idiomatic correctness
- →Reviewing Go implementations for best practices
- →Improving error handling patterns
- →Optimizing concurrency with channels
About this skill
Effective Go
Apply best practices and conventions from the official Effective Go guide to write clean, idiomatic Go code.
When to Apply
Use this skill automatically when:
- Writing new Go code
- Reviewing Go code
- Refactoring existing Go implementations
Key Reminders
Follow the conventions and patterns documented at https://go.dev/doc/effective_go, with particular attention to:
- Formatting: Always use
gofmt- this is non-negotiable - Naming: No underscores, use MixedCaps for exported names, mixedCaps for unexported
- Error handling: Always check errors; return them, don't panic
- Concurrency: Share memory by communicating (use channels)
- Interfaces: Keep small (1-3 methods ideal); accept interfaces, return concrete types
- Documentation: Document all exported symbols, starting with the symbol name
References
- Official Guide: https://go.dev/doc/effective_go
- Code Review Comments: https://github.com/golang/go/wiki/CodeReviewComments
- Standard Library: Use as reference for idiomatic patterns
When not to use it
- →When ignoring official Go documentation standards
- →When using non-idiomatic naming conventions
Limitations
- →Requires adherence to official Go documentation patterns
- →Restricted to the conventions defined in the Effective Go guide
How it compares
Unlike manual review, this skill enforces specific, non-negotiable standards like gofmt and interface sizing based directly on official Go documentation.
Compared to similar skills
effective-go side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| effective-go (this skill) | 323 | 9mo | No flags | Beginner |
| go-rig | 0 | 4mo | No flags | Intermediate |
| go-dev-guidelines | 14 | 9mo | No flags | Intermediate |
| opentelemetry-instrumentation-extension | 3 | 7mo | Review | Advanced |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by openshift
View all by openshift →You might also like
go-rig
mudrii
Use this skill when building, reviewing, or refactoring Go code in this repository. It adds process discipline for TDD/ATDD, package boundaries, dependency injection, and review quality, and complements the always-on rules in AGENTS.md.
go-dev-guidelines
jumppad-labs
This skill should be used when writing, refactoring, or testing Go code. It provides idiomatic Go development patterns, TDD-based workflows, project structure conventions, and testing best practices using testify/require and mockery. Activate this skill when creating new Go features, services, packages, tests, or when setting up new Go projects.
opentelemetry-instrumentation-extension
docker
Extend OpenTelemetry instrumentation when new functionality is added to the MCP Gateway. Use when (1) new operations/functions are added, (2) reviewing code for missing instrumentation, (3) user requests otel/telemetry additions, or (4) working with state-changing operations. Analyzes git diff, suggests instrumentation points following project standards in docs/telemetry/README.md, implements with approval, writes tests, updates documentation, and verifies with debug logging and docker logs.
golang
MadAppGang
Use when building Go backend services, implementing goroutines/channels, handling errors idiomatically, writing tests with testify, or following Go best practices for APIs/CLI tools.
code-formatting
openshift
MANDATORY: When writing Go tests, you MUST use 'When...it should...' format for ALL test names. When writing any Go code, you MUST remind user to run 'make lint-fix' and 'make verify'. These are non-negotiable HyperShift requirements.
tidb-test-guidelines
pingcap
Decide where to place TiDB tests and how to write them (basic structure, naming, testdata usage). Use when asked about test locations, writing conventions, shard_count limits, casetest categorization, or when reviewing test changes in code review.