golang-design-patterns

Applies idiomatic Go design patterns for constructors, error flow, resource management, and architecture.

1|Updated Jun 2, 2026
One-click install
npx skills add https://github.com/VerifiedOrganic/onboard --skill golang-design-patterns-verifiedorganic
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: golang-design-patterns
Source: https://github.com/VerifiedOrganic/onboard/tree/main/.agents/skills/golang-design-patterns
Command: npx skills add https://github.com/VerifiedOrganic/onboard --skill golang-design-patterns-verifiedorganic

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Go developers often face inconsistent design decisions across a codebase: constructors that break as APIs evolve, init() functions hiding dependencies, unbounded resource pools, and architectures that are either over-engineered or under-structured. This Skill provides a curated set of idiomatic Go patterns with clear rules for when each applies, so design and review decisions stay consistent and grounded in Go conventions. ## Core Features & Use Cases - Constructor and initialization patterns: Functional options with error-returning validation, avoiding init(), enums starting at 1, compile-time interface checks, and package-level regexp compilation. - Resource and resilience patterns: Immediate defer Close(), runtime.AddCleanup over SetFinalizer, bounded channel-based pools, timeouts on external calls, context-aware retries, and graceful shutdown via signal.NotifyContext. - Architecture guidance: Right-sized architecture selection by project scope, with detailed references for clean architecture, hexagonal (ports and adapters), and DDD including aggregates, value objects, and bounded contexts. - Use Case: When designing a new Go HTTP service, ask the agent to review your constructor API and shutdown logic; it will apply functional options, signal.NotifyContext-based graceful shutdown, and recommend an architecture matched to your project size. ## Quick Start Ask the agent to design a Go HTTP server constructor with configurable timeouts and connection limits using idiomatic patterns.

Frequently Asked Questions about golang-design-patterns

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I design a Go constructor with optional configuration?▼

Use the functional options pattern: define an Option type as a function that modifies the struct, provide With* functions for each setting, and accept variadic options in the constructor. Set defaults inside the constructor before applying options, and return an error from options when validation can fail.

Should I use functional options or the builder pattern in Go?▼

Functional options are preferred in Go because they scale better as APIs evolve, requiring one function per option with no breaking changes. Use the builder pattern only when you need complex validation between configuration steps.

When should I use clean architecture vs hexagonal architecture in Go?▼

Hexagonal architecture fits services with multiple entry points like HTTP, gRPC, and message consumers, using primary and secondary ports and adapters. Clean architecture fits medium-to-large services needing strict inward-pointing dependencies across entity, use case, and adapter layers. Neither is appropriate for small CLIs.

Why should I avoid init() for database setup in Go?▼

init() runs implicitly before main() and tests, cannot return errors, and creates hidden global dependencies that make testing unpredictable. Use explicit constructors like NewUserRepository(db) that accept dependencies as parameters instead.

How do I implement graceful shutdown in a Go HTTP server?▼

Use signal.NotifyContext to capture SIGINT and SIGTERM, run the server in a goroutine, then block on context cancellation. Shut down with a separate timeout context to drain in-flight requests, and close remaining resources like database connections afterward.

When should I use runtime.AddCleanup instead of SetFinalizer?▼

On Go 1.24 and later, prefer runtime.AddCleanup because it supports multiple cleanups per object, avoids object resurrection by passing a copy of the value, and works with cyclic references. SetFinalizer is the older API with unpredictable behavior.