From go-error-patterns
Use when Go error-handling design or function-type mismatches surface — including `func(string) error` vs concrete constructors, package-local type aliases, or concrete-vs-interface error choices, but not when the immediate task is a build or test failure.
How this skill is triggered — by the user, by Claude, or both
Slash command
/go-error-patterns:go-error-patternsThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Use this skill when a Go task is really about error-type design, shared helper signatures, or architecture boundaries around Go services and lambdas, and the next step is to normalize types instead of treating the problem as a generic build failure.
Use this skill when a Go task is really about error-type design, shared helper signatures, or architecture boundaries around Go services and lambdas, and the next step is to normalize types instead of treating the problem as a generic build failure.
func(string) error, but the available constructor returns a concrete error pointer type.func(string) *DomainError to satisfy func(string) error.error and returning a concrete pointer type.go build, go test, govulncheck, or CI parity issue.| Situation | Use this skill? | Route instead |
|---|---|---|
A helper accepts func(string) error, but the package constructor returns *DomainError | Yes | - |
A local alias like type OptionalString = optional.String is being proposed as the finished design | Yes | Stay here and use the shared owning type directly |
| The question is whether to keep one lambda per area/category or merge binaries | Yes | Stay here and keep one lambda per area unless a merge is explicitly requested |
go test ./... is failing and the root cause may be toolchain or CI isolation | No | go-build-and-test |
| The real problem is request validation or typing untrusted API input | No | schema-boundary-typing |
| No one yet understands the cause of the error or bug | No | systematic-debugging |
Required before editing
error interface.Helpful if present
func(string) error.Only investigate if encountered
go-build-and-test.func(string) error and the available constructor returns a concrete pointer, wrap the constructor in a local closure that returns error so the function type matches exactly.error in function signatures when callers only need the interface contract; keep concrete pointer types internal unless consumers truly need concrete-only behavior.go-build-and-test, schema-boundary-typing, or systematic-debugging.go build or go test command for the touched package if the design change is implemented in code.func(string) error, but my constructor returns *DomainError; what is the right pattern?"go test ./... only fails in CI after a Go version bump." (→ go-build-and-test)func(string) *ValidationError satisfy func(string) error in Go, and what should I pass instead?"type OptionalString = optional.String in a package; should that stay, or should we import the shared type directly?"references/error-constructor-patterns.md — Go code examples for closure wrapping, alias removal, and the concrete-vs-interface decision table../go-build-and-test/SKILL.md — adjacent Go skill for build, test, toolchain, and CI parity failures../schema-boundary-typing/SKILL.md — route here when the real task is boundary validation rather than Go error design../systematic-debugging/SKILL.md — route here when the root cause is still unknownCreates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.
npx claudepluginhub matt-riley/lucky-hat --plugin go-error-patterns