Skip to main content
skill CX Codex

go-dependency-injection — Claude Code skill

A skill that steers your agent toward constructor injection and a single composition root in main. Useful once globals creep in or tests get hard to write.

Install into Claude Code · Skills CLI (Vercel) All methods and platforms ↓
npx skills add eduardo-sl/go-agent-skills --skill go-dependency-injection -a claude-code
Open on GitHub

What go-dependency-injection does

This skill gives the agent a set of rules for wiring dependencies in Go. The default is constructor injection: a service takes its repository, payment gateway and logger as parameters instead of pulling them from package-level variables. All construction happens in one place — main, or a run function it calls — and the compiler checks the order for you.

There is a section on removing global state, including a migration path for legacy code. You introduce a struct that holds the dependency, leave a deprecated package-level wrapper delegating to one instance built in main, move callers across, then delete the wrapper. For narrow seams the skill suggests injecting a function rather than a full interface, like now func() time.Time.

On frameworks the stance is blunt: manual wiring holds up longer than people expect, and a hundred-line run stays readable. google/wire generates the calls at compile time; uber-go/fx and dig run a container and surface errors at startup. Pick one mechanism — one composition root, no mixing. The Go toolchain is required, while wire and fx are optional. A project rule or agent config that explicitly supersedes this skill wins.

What it helps with

  • replace a global singleton with an explicit dependency
  • gather all wiring into one main
  • make a component testable without touching process-wide state
  • decide between manual wiring and google/wire
  • move legacy code to constructors without a rewrite

Example prompts for the agent

  • Remove the global var DB and pass the dependency through the constructor
  • Move all wiring into main, drop the init() calls
  • Should I reach for google/wire here or keep manual wiring?

How to install go-dependency-injection

1Skills CLI (Vercel)

npx skills add eduardo-sl/go-agent-skills --skill go-dependency-injection -a claude-code

2Manually: put the files in place

~/.claude/skills/go-dependency-injection/SKILL.md

Copy the whole skill folder; for one project use .claude/skills/go-dependency-injection/

Step by step, with commands for each platform: How to install skills in Claude Code: five ways

Questions about go-dependency-injection

How do I install go-dependency-injection in Claude Code?

Run npx skills add eduardo-sl/go-agent-skills --skill go-dependency-injection -a claude-code. The skill lands at ~/.claude/skills/go-dependency-injection/SKILL.md.

What does go-dependency-injection do?

It lays out how to inject dependencies in Go: constructors, wiring in main, and getting rid of global state. It also covers when wire, fx and dig are worth it.

Do I need wire or fx for this skill?

No, both are optional. Manual wiring in main is the baseline, and the skill only suggests a framework when many components are involved.

Source text

SKILL.md · MIT
---
name: go-dependency-injection
description: >
  Dependency injection in Go: constructor injection, wiring in main,
  avoiding global state, and when frameworks (wire, fx, dig) earn their
  complexity. Use when: "dependency injection", "wire up dependencies",
  "inject this", "remove global state", "singleton in Go", "use
  google/wire", "uber fx", "make this testable".
  Not for: interface design (go-interface-design), directory structure
  (go-project-layout), test doubles and mocks (go-test-quality).
user-invocable: true
license: MIT
compatibility: Designed for Claude Code or similar AI coding agents working on Go projects. Requires the Go toolchain. wire and fx are optional.
allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(gofmt:*)
metadata:
  author: eduardo-sl
  version: "1.1.2"
---

# Go Dependency Injection

DI in Go is a pattern, not a framework: pass dependencies to
constructors, wire everything explicitly in `main`. Reach for a
framework only when manual wiring measurably hurts.

> Community default. A project skill or agent-config rule that explicitly
> supersedes `go-dependency-injection` takes precedence over this one.

## 1. Constructor Injection — the Default

```go
// ✅ Good — dependencies are explicit parameters
type OrderService struct {
    repo     OrderRepository
    payments PaymentGateway
    logger   *slog.Logger
}

func NewOrderService(repo OrderRepository, payments PaymentGateway, logger *slog.Logger) *OrderService {
    return &OrderService{repo: repo, payments: payments, logger: logger}
}

// ❌ Bad — hidden dependencies reached through globals
func (s *OrderService) Place(ctx context.Context, o Order) error {
    db := database.Get()        // global singleton
    log.Printf("placing order") // global logger
    // untestable without touching process-wide state
}
```

Rules:

- Accept interfaces for dependencies the service calls; return the
  concrete type from the constructor.
- Every dependency visible in the signature — if the list feels long,
  the type does too much (split it), don't hide deps to shorten it.
- Validate required deps in the constructor and return an error
  (or accept a nil-safe default, e.g. `logger = slog.Default()`).

## 2. The Composition Root

All wiring lives in one place — `main` (or a `run` function it calls).
Construction order is the dependency order, checked by the compiler:

```go
func run(ctx context.Context, cfg Config) error {
    db, err := store.Open(ctx, cfg.DatabaseURL)
    if err != nil {
        return fmt.Errorf("open db: %w", err)
    }
    defer db.Close()

    orderRepo := store.NewOrderRepo(db)
    payments := stripe.NewGateway(cfg.StripeKey)
    logger := slog.New(slog.NewJSONHandler(os.Stdout, nil))

    orders := service.NewOrderService(orderRepo, payments, logger)
    server := handler.NewServer(cfg.Addr, orders)

    return server.ListenAndServe(ctx)
}
```

- No package builds its own dependencies; it receives them.
- No `init()` wiring, no package-level `var DB *sql.DB`.
- Two binaries needing different wiring = two mains, same components.

## 3. Eliminating Global State

```go
// ❌ Before — package-level singleton
var defaultClient *api.Client

func Fetch(id string) (*Item, error) {
    return defaultClient.Get(id)
}

// ✅ After — the dependency moves into a struct
type Fetcher struct {
    client *api.Client
}

func NewFetcher(c *api.Client) *Fetcher { return &Fetcher{client: c} }

func (f *Fetcher) Fetch(id string) (*Item, error) {
    return f.client.Get(id)
}
```

Migration path for a legacy codebase: introduce the struct, keep a
deprecated package-level wrapper delegating to one instance built in
`main`, move callers over, delete the wrapper.

Acceptable package-level state: pure constants, compiled regexps,
`sync.Once`-guarded process singletons that hold no config.

## 4. Function Dependencies for Small Seams

A full interface is overkill for one function — inject the function:

```go
type Service struct {
    now     func() time.Time
    genID   func() string
    publish func(ctx context.Context, e Event) error
}

// Production: Service{now: time.Now, genID: uuid.NewString, publish: bus.Publish}
// Test:       Service{now: fixedTime, genID: constID, publish: capture}
```

## 5. When Frameworks Earn Their Complexity

Manual wiring scales further than expected — a 100-line `run` function
is still readable and compiler-checked. Consider a tool when wiring
crosses hundreds of components or many teams share one binary.

| Tool | Model | Trade-off |
|---|---|---|
| google/wire | Compile-time code generation | Wiring stays plain Go and compiler-checked; adds a codegen step |
| uber-go/fx | Runtime container + lifecycle | App lifecycle (start/stop hooks) managed; errors surface at runtime, magic in stack traces |
| uber-go/dig | Runtime container (fx's core) | Same runtime trade-offs, no lifecycle layer |

Decision rule: prefer manual wiring; if generation becomes necessary
prefer wire (failures at compile time beat failures at startup); adopt
fx only when you also want its lifecycle management and your team
accepts the runtime container.

Never mix models: one composition root, one mechanism.

## 6. Wire Example (when chosen)

```go
//go:build wireinject

func InitializeServer(cfg Config) (*handler.Server, error) {
    wire.Build(
        store.Open,
        store.NewOrderRepo,
        stripe.NewGateway,
        service.NewOrderService,
        handler.NewServer,
    )
    return nil, nil // replaced by generated code
}
```

`wire` generates the ordered constructor calls; the generated file is
committed and reviewed like handwritten code.

## Verification Checklist

1. Every service/handler receives dependencies via constructor parameters
2. No package-level mutable singletons (`var DB`, `var logger`, `Get()` accessors)
3. All wiring concentrated in main/run — no `init()` construction
4. Dependencies accepted as interfaces (or funcs), concrete types returned
5. Constructors validate required dependencies
6. Components testable by passing fakes — no process-global setup in tests
7. If a DI tool is used: exactly one, at the composition root only
8. `go build ./...` passes — wiring errors surface at compile time

© eduardo-sl · MIT · eduardo-sl/go-agent-skills

Similar skills

All skills for Backend and APIs →

From the same set11

git-commit A skill that makes your agent write commit messages in Conventional Commits style: typed, scoped, imperative. Useful when the repo history has turned into noise. CX Codex +1 ★ 83repo stars go-troubleshooting A skill that walks the agent through Go runtime diagnosis: panics, deadlocks, goroutine and memory leaks, race reports. Useful when a program crashes or hangs and the cause is unclear. CX Codex +1 ★ 83repo stars go-observability A skill that sets conventions for Go service telemetry: structured logs with log/slog, OpenTelemetry traces and metrics, SLO alerts. Useful once a service runs in production and you need to see what it does. CX Codex +1 ★ 83repo stars go-error-handling A skill that tells your agent how to create, wrap and inspect Go errors: %w wrapping, sentinel errors, custom types, errors.Is and errors.As. CX Codex +1 ★ 83repo stars go-context A skill that makes your coding agent handle context.Context in Go correctly: cancellation, timeouts, values and the usual anti-patterns. CX Codex +1 ★ 83repo stars go-project-layout Picks a folder layout for a new Go project: cmd/, internal/, or a flat root for small tools. Useful at the start, before the structure hardens. CX Codex +1 ★ 83repo stars go-grpc A skill that steers your coding agent through gRPC work in Go: proto contracts, error codes, deadlines, interceptors and streaming. CX Codex +1 ★ 83repo stars go-api-design A skill that steers the agent through Go HTTP handler design: routing, middleware, validation, pagination, graceful shutdown. Useful when you start a REST service or rework one. CX Codex +1 ★ 83repo stars

Project sponsors

Companies that keep this analytics open
Gold sponsor

Impressions, clicks and code copies — open statistics. We keep the numbers public for the same reason NeBlask itself is public. Become a sponsor