Go agents need more than syntax help. A useful guide distinguishes the job in front of the agent: broad implementation, package design, tests, concurrent work, error behavior, a measured performance question, review, an interface, context propagation, or public API documentation.
This guide selects source-vetted workflows from four independently maintained Go repositories. The first six are the broad, demand-backed starting points. The final four are lower-adoption specialists and are labelled accordingly. Every description follows its linked SKILL.md; installs are targeted skills.sh search observations from August 25, 2026.
How this list was picked
Broad starting points. The core entries cover implementation, package design, tests, concurrent work, errors, and measured performance. A direct answer routes each job to one skill rather than treating every Go task as the same workflow.
Four independent sources. Jeff Allan contributes one skill, ECC two, Samber three, and cxuu four. This replaces the previous single-repository catalogue while retaining the strongest source for each job.
Primary-source vetted. Each description follows its linked SKILL.md rather than a registry tagline, and every card links to the source for direct inspection.
Specialists are not defaults. The cxuu review, interface, context, and documentation cards solve distinct Go jobs but have lower observed adoption. They are useful when that boundary is explicit, not as the first skill for a normal change.
Top 10 Go skills at a glance
A comparative index of the top picks. Click any card to navigate directly to its detailed review.
Install counts are targeted skills.sh search observations from August 25, 2026. Core and specialist labels explain how each skill should be selected.
Implementation, Design, and Tests
Start with the broad implementation workflow, then narrow to package design or test work. These are the default answers for common Go changes; they do not replace a repository's established conventions.
golang-pro
17.1K installs Jeff AllanCore default
Best for: A broad Go implementation or service change
golang-pro is the broad entry point for a Go service or implementation task. Its workflow starts with architecture and interface review, then covers idiomatic implementation, context propagation, error handling, linting, profiling, benchmarks, and race-aware tests.
Use it when the work crosses several ordinary concerns but is not yet a focused concurrency, error-policy, or API-documentation task. When the boundary is clear, load the matching specialist below instead of stacking general guidance.
Interfaces before implementation details
Context-aware blocking operations and error wrapping
go vet, golangci-lint, table tests, and race checks
pprof and benchmarks for measured performance work
Best for: Package design, refactoring, and Go conventions
golang-patterns focuses on idiomatic Go decisions: useful zero values, consumer-owned interfaces, concrete returns, wrapped errors, package boundaries, and practical memory choices. It gives a clear answer when a local refactor might become a public package pattern.
Choose it over golang-pro when the real question is design clarity rather than broad implementation coverage. Its examples deliberately favor direct, boring code over clever abstractions.
Best for: New tests, regression coverage, fuzzing, and test cleanup
golang-testing covers the full Go testing loop: TDD, table-driven tests, subtests, helpers, temporary resources, HTTP handlers, benchmarks, fuzzing, and coverage. It is the focused answer when a change needs behavior proved rather than merely implemented.
Use it instead of the general implementation card once tests are the center of the task. Benchmark mechanics are included for test authors, while statistically defensible performance investigation belongs to golang-benchmark.
Table tests, subtests, helpers, and cleanup
HTTP handler tests and golden-file workflows
Benchmarks and fuzzing with the standard testing package
These are separate operational choices: what an error means, how concurrent work stops, and how a performance claim is measured. Pick the narrowest one that matches the failure mode.
golang-concurrency
37.0K installs samberCore specialty
Best for: Goroutines, channels, worker pools, and shared state
golang-concurrency treats every goroutine as a lifecycle decision. It covers ownership, context-aware selects, sender-owned channels, errgroup, bounded work, locks, atomics, and race or leak checks.
Choose it when code becomes concurrent or shares state. Do not use it as a general performance card: measure first with golang-benchmark, then return here only if the evidence points to contention, scheduling, or cancellation.
Explicit exits and context-aware blocking selects
Channel ownership, errgroup, and bounded concurrency
Mutex, atomic, sync.Map, and singleflight decisions
Best for: Error contracts, wrapping, and operational failure paths
golang-error-handling provides an explicit policy for checked errors, contextual %w wrapping, errors.Is and errors.As, sentinel/custom error types, errors.Join, and panic boundaries. It also keeps logging and propagation at one handling boundary.
Choose it for a caller-visible failure contract or an operational error path. Context propagation and goroutine shutdown are related concerns, but their rules live in the context and concurrency specialists.
Best for: Benchmarks, pprof, traces, and performance regression evidence
golang-benchmark is for a real performance question with a measurable baseline. It covers b.Loop and allocation reporting, controlled repeated runs, benchstat, CPU and memory profiles, traces, and evidence for regression checks.
Use it only after a performance concern is observable. Tests establish correctness; this skill establishes execution behavior, then sends a confirmed concurrency issue back to golang-concurrency.
Source-matched benchmark files and allocation reporting
These lower-adoption skills are specialist answers, not starting defaults. Use one when the task is explicitly a review, an interface decision, context propagation, or documentation of a public Go surface.
go-code-review
1.4K installs cxuuSpecialist · lower adoption
Best for: A Go-specific code review before shipping
go-code-review starts with gofmt, go vet, and lint output, then reviews a Go diff across errors, contexts, concurrency, interfaces, declarations, tests, documentation, imports, and logging. Findings must be tied to a specific line and rule.
Use it after implementation when a language-specific review is the job. It complements, rather than replaces, a general review of the product requirement and architecture.
Mechanical checks before manual diff review
Line-referenced must-fix, should-fix, and nit findings
Go-specific checks for errors, contexts, and concurrency
Best for: Interfaces, receiver choices, embedding, and type assertions
go-interfaces is the narrow answer for interface design. It places interfaces with consumers, prefers concrete returns when callers need the full type, uses safe assertions, and explains when compile-time satisfaction checks are useful.
Choose it when an abstraction or method-set decision is the question. For wider package design, use golang-patterns; for a final review, use go-code-review.
Best for: context.Context signatures, timeouts, and request lifetimes
go-context focuses entirely on context.Context: put it first in signatures, never store it in structs, derive and cancel it deliberately, and reserve values for request-scoped data that cannot be passed explicitly.
Choose it when cancellation or deadline propagation is the real boundary. Use golang-concurrency when goroutine ownership or synchronization is the larger issue.
Best for: Public packages, exported APIs, examples, and documentation review
go-documentation covers package comments, exported-name documentation, non-obvious behavior, cleanup and error contracts, formatting, and runnable examples. It keeps comments useful without restating type signatures.
Choose it when a public Go surface needs to be explained or reviewed. It is not a general prose tool and does not replace the implementation or code-review workflows.
Package and exported-name comment conventions
Behavior, cleanup, error, and concurrency boundaries
Start with the broadest skill only when the work is genuinely broad. Move straight to a focused card when the task already names its boundary. The four lower-adoption cxuu cards are deliberate specialist choices, not a default stack for every Go change.
1.Build an ordinary Go service or feature. Use golang-pro as the broad default for implementation work that spans idiomatic code, interfaces, context, errors, validation, and tests. Do not add every specialist by habit; use the next choices when the task is already narrower.
2.Design a package or prove behavior. Choose golang-patterns when the work is package shape, API design, refactoring, or Go conventions. Choose golang-testing when the task is new behavior, regression coverage, fuzzing, or test cleanup.
3.Name the runtime failure mode. Choose golang-error-handling for a failure a caller must interpret. Choose golang-concurrency for goroutines, shared state, channels, worker limits, or leaks. Choose golang-benchmark only when a performance question has a measurable baseline.
4.Use a cxuu specialist only for its explicit boundary. Use go-code-review for a completed Go diff, go-interfaces for a method-set or abstraction decision, go-context for cancellation/deadline propagation, and go-documentation for public package or API documentation. These are focused lower-adoption tools, not competing defaults.
The Go failure path agents miss
A request can be correct at each line and still fail as a unit of work. An HTTP handler starts a goroutine with context.Background, the client disconnects, the database call keeps running, and a later error is wrapped with a driver detail that an HTTP layer now treats as public behavior. That sequence crosses context, concurrency, and error contracts. No single general-purpose Go skill makes all three decisions well.
Propagate the incoming context, make the goroutine's exit condition explicit, and decide whether the inner error is intended for callers before choosing %w. Then exercise the resulting path with a test and the race detector. That is more useful than adding a worker pool or a retry because the code happens to be running concurrently.
Benchmarks answer a different question than tests
A test tells you that a result is correct for an input. A benchmark tells you how a specific execution behaves under a controlled loop. The two are complementary. The benchmark source calls for repeated runs, allocation reporting, profiles, and statistical comparison so a small scheduling difference does not become a made-up improvement.
If a profile points at lock contention, channel backpressure, or a goroutine that never exits, return to the concurrency skill. If it points at an external call, changing Go allocations will not repair the system. The measured bottleneck decides the next skill.
Keep Go skills visible with LazySkills
LazySkills scans installed skills, shows which agents can see them, diagnoses broken configurations, and searches the same skills.sh registry used for this guide. Install the catalog manager, then add the narrow Go workflow that fits the work in front of the agent.
Which Go skill should an agent load first for a normal change?
Start with golang-pro when the task spans ordinary implementation concerns in an existing Go service. Use golang-patterns instead when the question is package shape, API design, or an idiomatic refactor, and golang-testing when proving behavior is the main job. The four cxuu entries are explicit lower-adoption specialists, not default starting points.
Which skill should I use for a Go interface decision?
Use go-interfaces when deciding whether an interface is needed, where it belongs, how a constructor should return a type, or whether receiver and embedding choices satisfy a method set. Use golang-patterns for the larger package-design question, and go-code-review when the interface decision is already in a completed diff.
How should an agent handle a wrapped Go error?
Use golang-error-handling. It treats errors as caller-visible contracts: check returned errors, wrap with fmt.Errorf and %w only when callers need the cause, inspect with errors.Is or errors.As, and log or return at one handling boundary instead of both.
When is go-context different from golang-concurrency?
Use go-context for the propagation rules: context first in a signature, deadlines, cancellation, and request-scoped values. Use golang-concurrency when the question is goroutine lifetime, channel ownership, synchronization, errgroup, worker limits, races, or leaks. A request can need both, but they answer different failure modes.
Do benchmarks replace tests for a Go change?
No. golang-testing establishes correct behavior; golang-benchmark establishes measured execution behavior. Load golang-benchmark only when there is a baseline or observed performance question, then use repeated controlled runs, profiles, and statistical comparison before claiming an improvement.
Which Go skill is for review or public API documentation?
Use go-code-review for a completed Go diff that needs language-specific findings backed by line references. Use go-documentation for package comments, exported API documentation, cleanup and error notes, and runnable examples. Both are focused specialist choices rather than general implementation defaults.
svgdiagram.ai 
