gophers

Dispatchable subagents that wrap one or more **gophers** skills. Each agent is a focused worker — it loads the underlying skill, runs a fixed process on input the dispatcher supplies, and returns a structured text payload. **Agents never mutate state outside their sandbox** (no commits, no PR comments, no force-writes).

Dispatch when a Go service needs a clean-architecture audit. Walks the module's import graph and flags dependency-direction violations (delivery importing repository, usecase touching SQL or gin.Context), framework leaks into the domain, and ORM types crossing layer boundaries — with file:line citations and a refactor sequence. Use before a refactor sprint, when onboarding a service, or when tests require a live database.

Dispatch when a Go pull request, diff, patch, or set of staged changes needs a community-style review before merge. Walks the diff topic-by-topic using the go-code-review skill (formatting, errors, naming, concurrency, interfaces, data structures, security, declarations, functions, style, logging, imports, generics, testing) and returns findings grouped by Must Fix / Should Fix / Nit with file:line citations. Use proactively on any PR larger than a one-line typo fix.

Dispatch when a Go codebase has accumulated repeated patterns (idiomatic or anti-) worth capturing as a new gophers skill. Walks the module, surfaces repeated structural shapes (3+ occurrences in 2+ packages), confirms each candidate is not already covered by an existing skill, and emits a draft SKILL.md proposal that follows the gophers template. Use periodically (monthly / per-quarter) on services that have grown new conventions, or after a large refactor that introduced new patterns.

Dispatch when a Go function, method, or package needs new tests authored from scratch or extended with missing cases. Generates table-driven tests, subtests, helpers, and (where appropriate) httptest harnesses, fuzz seeds, or testing/synctest scaffolds — following the go-testing skill conventions (useful failures, t.Helper, t.Parallel, no assertion libraries by default). Returns a complete *_test.go file ready to drop into the package.

Use when scaffolding or refactoring a Go service into a framework-agnostic clean (hexagonal) architecture: Domain, Usecase, Repository, Delivery layers, inward dependency rule, 'framework/database is a detail'. Apply when untangling a monolith or checking whether business logic is testable without HTTP or DB.

Invoke this skill to systematically review a Go change against community style standards before merging. Walks the diff topic by topic — formatting, errors, naming, concurrency, interfaces, data structures, security, declarations, functions, style, logging, imports, generics, testing — flagging issues with line references and severity (must-fix / should-fix / nit). Apply proactively before any Go PR ships.

Use when writing or reviewing Go code for clarity, formatting, control flow, variable declarations, switch usage, and function design. Covers the priority order (clarity > simplicity > concision > maintainability > consistency), gofmt rules, early-return / no-else patterns, switch over if-else chains, slice/map initialization, and value-vs-pointer choices. Apply proactively to every Go change, even when the user has not asked about style.

Use when writing or reviewing concurrent Go code — goroutines, channels, select, mutexes, atomics, errgroup, singleflight, worker pools, or fan-out/fan-in pipelines. Apply proactively whenever a goroutine is spawned, a shared field is mutated, or a channel is created, even if the user has not asked about concurrency. Does not cover context.Context patterns (see go-context).

Use when designing, propagating, or debugging context.Context flow in Go — first-parameter placement, deadlines and cancellation, request-scoped values, WithoutCancel for fire-and-forget work, and key-collision-safe value patterns. Apply proactively whenever a function takes ctx, spawns work, or accepts request-scoped data, even if the user has not asked about context.