service-go

Implements Go service patterns with interfaces, stubs, factories, and fx dependency injection wiring.

4|Updated Jul 30, 2026
One-click install
npx skills add https://github.com/gabriellst/codm --skill service-go-gabriellst
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: service-go
Source: https://github.com/gabriellst/codm/tree/main/.claude/skills/service/go
Command: npx skills add https://github.com/gabriellst/codm --skill service-go-gabriellst

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? It guides developers in structuring Go services correctly within a DDD backend, preventing common mistakes like unnecessary interfaces, global state, and misplaced dependency injection wiring. ## Core Features & Use Cases - Service Scoping Rules: Distinguishes context-local services (registered in <ctx>/module.go) from cross-context infrastructure services in core/services/ wired at the application root. - Interface and Implementation Patterns: Enforces interfaces only when multiple implementations exist, compile-time checks via var _ FooService = (*StubFooService)(nil), and constructor-based dependency injection. - fx Wiring Guidance: Covers fx.As(new(FooService)) annotation for interface consumers and the factory pattern when implementations switch at runtime rather than wire-up time. - Use Case: When adding a transcoding service to a Go bounded context, follow the registry patterns to define the interface, write a stub implementation, and register it in the context module with fx. ## Quick Start Ask the AI to create a new Go service for a bounded context following the service-go patterns, including the interface, stub implementation, and fx module registration.

Frequently Asked Questions about service-go

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

FAQPage Schema
How do I structure a service in Go with dependency injection?

Define an interface only when multiple implementations exist, create a stub or concrete struct receiving dependencies via its constructor, and register it with fx using fx.As(new(FooService)) when consumers depend on the interface.

When should I use an interface versus a concrete struct in Go services?

Use an interface only when multiple implementations exist or are planned, such as a stub for testing and a real implementation for production. For a single permanent implementation, provide the concrete struct directly and add an interface later if needed.

What is the difference between the factory pattern and fx.As wiring in Go?

Use fx.As when the implementation is selected once at wire-up time. Use a factory struct when the implementation must be chosen at runtime, such as switching gateways based on a platform enum; the factory receives concrete types without fx.As.

Where should cross-context infrastructure services be registered in a Go fx app?

Cross-context infrastructure services like mediators, outbox dispatchers, and units of work live in core/services/ and are wired at the application root in cmd/api/main.go, not inside individual context modules.

Why is package-level global state a bad practice in Go services?

Package-level globals like a shared http.Client make services untestable and hide dependencies. Instead, inject all dependencies through the constructor so each service instance owns its clients and configuration explicitly.

When should logic go on an entity instead of a service in Go?

Logic involving a single entity's data and invariants, such as status transitions, belongs in an entity method. Services are for cross-aggregate coordination, external API calls, and infrastructure operations like storage or email.