Golang Dependency Injection

What it does

When your agent uses it

• Designing service architecture
• Setting up dependency injection
• Refactoring tightly coupled code
• Managing singletons

Example prompts

• “/golang-dependency-injection”

Requirements

• Compatibility (from SKILL.md): Designed for Claude Code, Codex or similar harness, and for projects using Golang.
• Pre-approved tools (allowed-tools): Read, Edit, Write, Glob, Grep, Bash(go:*), Bash(golangci-lint:*), Bash(git:*), Agent, WebFetch, mcp__context7__resolve-library-id, mcp__context7__query-docs, AskUserQuestion

Workflow steps

10 steps, taken from the first numbered list in SKILL.md.

1. 1Dependencies MUST be injected via constructors — NEVER use global variables or init() for service setup
2. 2Small projects (< 10 services) SHOULD use manual constructor injection — no library needed
3. 3Interfaces MUST be defined where consumed, not where implemented — accept interfaces, return structs
4. 4NEVER use global registries or package-level service locators
5. 5The DI container MUST only exist at the composition root (main() or app startup) — NEVER pass the container as a dependency
6. 6Prefer lazy initialization — only create services when first requested
7. 7Use singletons for stateful services (DB connections, caches) and transients for stateless ones
8. 8Mock at the interface boundary — DI makes this trivial
9. 9Keep the dependency graph shallow — deep chains signal design problems
10. 10Choose the right DI library for your project size and team — see the decision table below

What it can do on your machine

Read from SKILL.md and the folder at commit 8e899e2. It shows what the files ask for, not the result of running them.

• Tool permissions

  Pre-approves these tools, so the agent can use them without asking each time:

  • Read
  • Edit
  • Write
  • Glob
  • Grep
  • Bash(go:*)
  • Bash(golangci-lint:*)
  • Bash(git:*)
  • Agent
  • WebFetch

  …and 3 more on the same allowed-tools line.

  From allowed-tools in the SKILL.md frontmatter.

• Runs code

  No scripts in the folder and no shell commands in SKILL.md (its code samples are go).

  From the folder's file list and the shell code blocks in SKILL.md.

• Network

  Links to these hosts (documentation or services it may open):

  • github.com
  • do.samber.dev
  • uber-go.github.io

  From URLs in SKILL.md, links to its own repository left out.

• Credentials

  Names no API keys, tokens, secrets or passwords.

  From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

• Compatibility

  Designed for Claude Code, Codex or similar harness, and for projects using Golang.

  From compatibility in the SKILL.md frontmatter.

Context cost

Golang Dependency Injection loads about 3.2k tokens when it runs, and up to ~5.8k if it reads all its reference files. Until then it costs about 193 tokens; SKILL.md has 1,035 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it

~193

When it runs · the whole SKILL.md, loaded when a task matches

~3.2k

With references · SKILL.md plus every file in references/, read only if the agent opens them

~5.8k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from samber/cc-skills-golang at commit 8e899e2, republished under its MIT licence (© samber). 1,035 words, ~3,242 tokens.

name

golang-dependency-injection

description

Comprehensive guide for dependency injection (DI) in Golang. Covers why DI matters (testability, loose coupling, separation of concerns, lifecycle management), manual constructor injection, and DI library comparison (google/wire, uber-go/dig, uber-go/fx, samber/do). Use this skill when designing service architecture, setting up dependency injection, refactoring tightly coupled code, managing singletons or service factories, or when the user asks about inversion of control, service containers, or wiring dependencies in Go. For a specific DI library, → See `samber/cc-skills-golang@golang-google-wire`, `samber/cc-skills-golang@golang-uber-dig`, `samber/cc-skills-golang@golang-uber-fx`, or `samber/cc-skills-golang@golang-samber-do` skills.

allowed-tools

Read, Edit, Write, Glob, Grep, Bash(go:*), Bash(golangci-lint:*), Bash(git:*), Agent, WebFetch, mcp__context7__resolve-library-id, mcp__context7__query-docs, AskUserQuestion

compatibility

Designed for Claude Code, Codex or similar harness, and for projects using Golang.

user-invocable

true

license

MIT

metadata.author

samber

metadata.version

1.3.1

paths

**/*.go

// ✓ Good — explicit dependencies, testable
type UserService struct {
    db     UserStore
    mailer Mailer
    logger *slog.Logger
}

func NewUserService(db UserStore, mailer Mailer, logger *slog.Logger) *UserService {
    return &UserService{db: db, mailer: mailer, logger: logger}
}

// main.go — manual wiring
func main() {
    logger := slog.Default()
    db := postgres.NewUserStore(connStr)
    mailer := smtp.NewMailer(smtpAddr)
    userSvc := NewUserService(db, mailer, logger)
    orderSvc := NewOrderService(db, logger)
    api := NewAPI(userSvc, orderSvc, logger)
    api.ListenAndServe(":8080")
}

// ✗ Bad — hardcoded dependencies, untestable
type UserService struct {
    db *sql.DB
}

func NewUserService() *UserService {
    db, _ := sql.Open("postgres", os.Getenv("DATABASE_URL")) // hidden dependency
    return &UserService{db: db}
}

// Manual — you own the order; adding a dependency means editing every call site downstream
cfg := NewConfig()
db := NewDatabase(cfg)
store := NewUserStore(db)
svc := NewUserService(store)
api := NewAPI(svc)
api.Run()
// No shutdown hooks, health checks, or lazy loading — add them yourself

// Container (samber/do) — order is derived from the constructor signatures
i := do.New()
do.Provide(i, NewConfig)
do.Provide(i, NewDatabase)
do.Provide(i, NewUserStore)
do.Provide(i, NewUserService)
api := do.MustInvoke[*API](i)
api.Run()
defer i.Shutdown() // shutdown and health checks come from the container

// Define a mock
type MockUserStore struct {
    users map[string]*User
}

func (m *MockUserStore) FindByID(ctx context.Context, id string) (*User, error) {
    u, ok := m.users[id]
    if !ok {
        return nil, ErrNotFound
    }
    return u, nil
}

// Test with manual injection
func TestUserService_GetUser(t *testing.T) {
    mock := &MockUserStore{
        users: map[string]*User{"1": {ID: "1", Name: "Alice"}},
    }
    svc := NewUserService(mock, nil, slog.Default())

    user, err := svc.GetUser(context.Background(), "1")
    if err != nil {
        t.Fatalf("unexpected error: %v", err)
    }
    if user.Name != "Alice" {
        t.Errorf("got %q, want %q", user.Name, "Alice")
    }
}

func TestUserService_WithDo(t *testing.T) {
    // Create a test injector with mock implementation
    testInjector := do.New()

    // Provide the mock UserStore interface
    do.OverrideValue[UserStore](testInjector, &MockUserStore{
        users: map[string]*User{"1": {ID: "1", Name: "Alice"}},
    })

    // Provide other real services as needed
    do.Provide[*slog.Logger](testInjector, func(i *do.Injector) (*slog.Logger, error) {
        return slog.Default(), nil
    })

    svc := do.MustInvoke[*UserService](testInjector)
    user, err := svc.GetUser(context.Background(), "1")
    // ... assertions
}

© samber, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 5 other files (references) in skills/golang-dependency-injection of samber/cc-skills-golang.

• SKILL.md
• evals/evals.json
• references/google-wire.md
• references/manual-di.md
• references/samber-do.md
• references/uber-dig-fx.md

Open the folder on GitHubat commit 8e899e2