Agent skill

Golang Dependency Injection

by context-labs in context-labs/whip

Dependency injection (DI) in Golang — why DI matters, manual constructor injection, library comparison.

MITAuto-check passedDevelopment

Install Golang Dependency Injection

skills CLI
$ npx skills add context-labs/whip --skill golang-dependency-injection -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install context-labs/whip golang-dependency-injection --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/context-labs/whip.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/golang-dependency-injection .claude/skills/golang-dependency-injection && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
golang-dependency-injection
GitHub stars
1.1k
Token cost
~3.1k tokens
SKILL.md length
954 words
Files
6 (incl. references)
Skills in repo
40
Repo updated
First seen
Licence
MIT

At a glance

Dependency injection (DI) in Golang — why DI matters, manual constructor injection, library comparison.

  • Works in 10 steps: Dependencies MUST be injected via… → Small projects (< 10 services) SHOULD… → Interfaces MUST be defined where… → …
  • Designing service architecture
  • SKILL.md covers Best Practices Summary, Why Dependency Injection?, Manual Constructor Injection… and DI Library Comparison, plus 5 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Golang Dependency Injection is an agent skill from context-labs/whip. Dependency injection (DI) in Golang — why DI matters, manual constructor injection, library comparison. Use when designing service architecture or wiring dependencies. For google/wire, dig, fx, samber/do → golang-google-wire, golang-uber-dig, golang-uber-fx, golang-samber-do.

Its SKILL.md is about 3.1k tokens, which your agent loads only when the skill is triggered. The skill folder holds 7 other files, including reference files (for example `evals/evals.json`, `references/google-wire.md` and `references/manual-di.md`). Compatibility notes: Designed for Claude Code, Codex or similar harness, and for projects using Golang.

It sits in Development, covering Design patterns. It works with Go. The repository describes itself as: A fast coding-agent harness in Go. Tool-use loop, bubbletea TUI, provider-routable models with live catalog discovery, MCP support, background subagents. One binary, no runtime… The licence is MIT.

When your agent uses it

  • Designing service architecture
  • Wiring dependencies

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. Dependencies MUST be injected via constructors — NEVER use global variables or init() for service setup
  2. Small projects (< 10 services) SHOULD use manual constructor injection — no library needed
  3. Interfaces MUST be defined where consumed, not where implemented — accept interfaces, return structs
  4. NEVER use global registries or package-level service locators
  5. The DI container MUST only exist at the composition root (main() or app startup) — NEVER pass the container as a dependency
  6. Prefer lazy initialization — only create services when first requested
  7. Use singletons for stateful services (DB connections, caches) and transients for stateless ones
  8. Mock at the interface boundary — DI makes this trivial
  9. Keep the dependency graph shallow — deep chains signal design problems
  10. Choose 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 8876467. 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.1k tokens when it runs, and up to ~5.5k if it reads all its reference files. Until then it costs about 78 tokens; SKILL.md has 954 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~78
When it runs · the whole SKILL.md, loaded when a task matches
~3.1k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~5.5k

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

Auto-check passed

The automated check found no risky patterns in SKILL.md.

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 context-labs/whip at commit 8876467, republished under its MIT licence (© context-labs). 954 words, ~3,056 tokens.

Download SKILL.mdSave it as .claude/skills/golang-dependency-injection/SKILL.md (or your agent's skills folder). This skill also uses 5 other files; get the full folder from GitHub.
name
golang-dependency-injection
description
Dependency injection (DI) in Golang — why DI matters, manual constructor injection, library comparison. Use when designing service architecture or wiring dependencies. For google/wire, dig, fx, samber/do → `golang-google-wire`, `golang-uber-dig`, `golang-uber-fx`, `golang-samber-do`.
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.0
paths
**/*.go

Persona: You are a Go software architect. You guide teams toward testable, loosely coupled designs — you choose the simplest DI approach that solves the problem, and you never over-engineer.

Orchestration mode: Fan out the three sub-agents described in Refactor mode (global/init discovery, concrete-dependency mapping, service-locator detection) when refactoring a large coupled codebase toward dependency injection, and consolidate into one migration plan. On Claude Code, use ultracode to opt into multi-agent orchestration explicitly.

Modes:

  • Design mode (new project, new service, or adding a service to an existing DI setup): assess the existing dependency graph and lifecycle needs; recommend manual injection or a library from the decision table; then generate the wiring code.
  • Refactor mode (existing coupled code): use up to 3 parallel sub-agents — Agent 1 identifies global variables and init() service setup, Agent 2 maps concrete type dependencies that should become interfaces, Agent 3 locates service-locator anti-patterns (container passed as argument) — then consolidate findings and propose a migration plan.

Community default. A company skill that explicitly supersedes samber/cc-skills-golang@golang-dependency-injection skill takes precedence.

Dependency Injection in Go

Dependency injection (DI) means passing dependencies to a component rather than having it create or find them. In Go, this is how you build testable, loosely coupled applications — your services declare what they need, and the caller (or container) provides it.

This skill is not exhaustive. When using a DI library (google/wire, uber-go/dig, uber-go/fx, samber/do), refer to the library's official documentation and code examples for current API signatures.

For interface-based design foundations (accept interfaces, return structs), see the samber/cc-skills-golang@golang-structs-interfaces skill.

Best Practices Summary

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

Why Dependency Injection?

Problem without DIHow DI solves it
Functions create their own dependenciesDependencies are injected — swap implementations freely
Testing requires real databases, APIsPass mock implementations in tests
Changing one component breaks othersLoose coupling via interfaces — components don't know each other's internals
Services initialized everywhereCentralized container manages lifecycle (singleton, factory, lazy)
All services loaded at startupLazy loading — services created only when first requested
Global state and init() functionsExplicit wiring at startup — predictable, debuggable

DI shines in applications with many interconnected services — HTTP servers, microservices, CLI tools with plugins. For a small script with 2-3 functions, manual wiring is fine. Don't over-engineer.

Manual Constructor Injection (No Library)

For small projects, pass dependencies through constructors. See Manual DI examples for a complete application example.

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")
}
go
// ✗ 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 DI breaks down when:

  • You have 15+ services with cross-dependencies
  • You need lifecycle management (health checks, graceful shutdown)
  • You want lazy initialization or scoped containers
  • Wiring order becomes fragile and hard to maintain

DI Library Comparison

Go has three main approaches to DI libraries:

Show full SKILL.md (371 more words)Show less
Decision Table
CriteriaManualgoogle/wireuber-go/dig + fxsamber/do
Project sizeSmall (< 10 services)Medium-LargeLargeAny size
Type safetyCompile-timeCompile-time (codegen)Runtime (reflection)Compile-time (generics)
Code generationNoneRequired (wire_gen.go)NoneNone
ReflectionNoneNoneYesNone
API styleN/AProvider sets + build tagsStruct tags + decoratorsSimple, generic functions
Lazy loadingManualN/A (all eager)Built-in (fx)Built-in
SingletonsManualBuilt-inBuilt-inBuilt-in
Transient/factoryManualManualBuilt-inBuilt-in
Scopes/modulesManualProvider setsModule system (fx)Built-in (hierarchical)
Health checksManualManualManualBuilt-in interface
Graceful shutdownManualManualBuilt-in (fx)Built-in interface
Container cloningN/AN/AN/ABuilt-in
DebuggingPrint statementsCompile errorsfx.Visualize()ExplainInjector(), web interface
Go versionAnyAnyAny1.18+ (generics)
Learning curveNoneMediumHighLow
Quick Comparison: Same App, Four Ways

The dependency graph: Config -> Database -> UserStore -> UserService -> API

Manual:

go
cfg := NewConfig()
db := NewDatabase(cfg)
store := NewUserStore(db)
svc := NewUserService(store)
api := NewAPI(svc)
api.Run()
// No automatic shutdown, health checks, or lazy loading

google/wire:

go
// wire.go — then run: wire ./...
func InitializeAPI() (*API, error) {
    wire.Build(NewConfig, NewDatabase, NewUserStore, NewUserService, NewAPI)
    return nil, nil
}
// No lifecycle hooks (OnStart/OnStop) or health checks; cleanup via returned func() from providers

uber-go/fx:

go
app := fx.New(
    fx.Provide(NewConfig, NewDatabase, NewUserStore, NewUserService),
    fx.Invoke(func(api *API) { api.Run() }),
)
app.Run() // manages lifecycle, but reflection-based

samber/do:

go
i := do.New()
do.Provide(i, NewConfig)
do.Provide(i, NewDatabase)    // auto shutdown + health check
do.Provide(i, NewUserStore)
do.Provide(i, NewUserService)
api := do.MustInvoke[*API](i)
api.Run()
// defer i.Shutdown() — handles all cleanup automatically

Testing with DI

DI makes testing straightforward — inject mocks instead of real implementations:

go
// 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")
    }
}
Testing with samber/do — Clone and Override

Container cloning creates an isolated copy where you override only the services you need to mock:

go
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
}

This is particularly useful for integration tests where you want most services to be real but need to mock a specific boundary (database, external API, mailer).

When to Adopt a DI Library

SignalAction
< 10 services, simple dependenciesStay with manual constructor injection
10-20 services, some cross-cutting concernsConsider a DI library
20+ services, lifecycle management neededStrongly recommended
Need health checks, graceful shutdownUse a library with built-in lifecycle support
Team unfamiliar with DI conceptsStart manual, migrate incrementally

Common Mistakes

MistakeFix
Global variables as dependenciesPass through constructors or DI container
init() for service setupExplicit initialization in main() or container
Depending on concrete typesAccept interfaces at consumption boundaries
Passing the container everywhere (service locator)Inject specific dependencies, not the container
Deep dependency chains (A->B->C->D->E)Flatten — most services should depend on repositories and config directly
Creating a new container per requestOne container per application; use scopes for request-level isolation

Cross-References

  • → See samber/cc-skills-golang@golang-samber-do skill for detailed samber/do usage patterns
  • → See samber/cc-skills-golang@golang-structs-interfaces skill for interface design and composition
  • → See samber/cc-skills-golang@golang-testing skill for testing with dependency injection
  • → See samber/cc-skills-golang@golang-project-layout skill for DI initialization placement

References

© context-labs, 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 .agents/skills/golang-dependency-injection of context-labs/whip.

  • 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 8876467

Compare with similar skills

Golang Dependency Injection next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Golang Dependency Injection compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Golang Dependency Injection this skillcontext-labs/whip1.1k—~3.1kAutomated safety check: PassMIT
Context Handling in fp-goIBM/fp-go2k—~4.2kAutomated safety check: PassApache-2.0
Typed Dependencies with fp-go EffectIBM/fp-go2k—~4.3kAutomated safety check: PassApache-2.0
fp-go Lenses for Go StructsIBM/fp-go2k—~4.3kAutomated safety check: PassApache-2.0
Golang Dependency Injectionsamber/cc-skills-golang3.4k—~3.2kAutomated safety check: PassMIT
Ddd Teaching Skillsazardev/goca299—~5.3kAutomated safety check: PassMIT

Similar skills

  • Official

    Covers handling Go's context.Context idiomatically in fp-go code: reading and scoping context through operators, timeouts, cancellation and converting ctx-first functions.

    2k GitHub stars~4.2k tokensUpdated today
    DevelopmentAuto-check passed
  • Teaches an agent to write fp-go v2 services with the Effect type, carrying dependencies in its type parameter instead of in context.Context or parameters.

    2k GitHub stars~4.3k tokensUpdated today
    DevelopmentAuto-check passed
  • Official

    Generates or hand-writes composable lenses for the fp-go library so nested Go structs can be read and updated immutably.

    2k GitHub stars~4.3k tokensUpdated today
    DevelopmentAuto-check passed
  • Golang Dependency Injection

    samber/cc-skills-golang

    Comprehensive guide for dependency injection (DI) in Golang.

    3.4k GitHub stars~3.2k tokensUpdated 8 days ago
    DevelopmentAuto-check passed
  • Ddd Teaching Skill

    sazardev/goca

    Enseña Domain-Driven Design y Clean Architecture de forma guiada usando Goca CLI.

    299 GitHub stars~5.3k tokensUpdated 2 mo ago
    DevelopmentAuto-check passed
  • Official

    Guides writing or reviewing point-free, first-match-wins case lists in fp-go v2 Go code instead of switch statements and if-else chains.

    2k GitHub stars~2.8k tokensUpdated today
    DevelopmentAuto-check passed

More from context-labs/whip

All 40 skills in this repo
  • Golang Lint

    context-labs/whip

    Linting best practices and golangci-lint configuration for Go — running linters, configuring .golangci.yml, nolint suppressions, selecting linters.

    1.1k GitHub starsUsed in 2 repos~1.8k tokens
    Auto-check passed
  • Golang Project Layout

    context-labs/whip

    Golang project layouts and workspaces. An agent skill from context-labs/whip.

    1.1k GitHub starsUsed in 1 repo~1.8k tokens
    Auto-check passed
  • Golang Pkg Go Dev

    context-labs/whip

    Golang package/module docs via godig, a pkg.go.dev API client (CLI + MCP) — APIs, symbols, versions, importers, licenses, vulnerabilities.

    1.1k GitHub starsUsed in 2 repos~3k tokens
    Auto-check passed
  • Golang Stretchr Testify

    context-labs/whip

    Golang testing with stretchr/testify — assert, require, mock, suite: assertions, mock expectations, argument matchers, suite lifecycle, Eventually, JSONEq.

    1.1k GitHub starsUsed in 2 repos~1.8k tokens
    Auto-check passed
  • CI/CD with GitHub Actions for Golang — testing, linting, SAST, security scanning, coverage, Dependabot, Renovate, GoReleaser, release pipelines.

    1.1k GitHub stars~3.5k tokensUpdated 5 days ago
    Auto-check passed
  • Golang Data Structures

    context-labs/whip

    Golang data structures — slices/maps internals (capacity growth, preallocation, hash buckets), slices/maps packages, container/list/heap/ring, strings.Builder vs bytes.Buffer, generic collections…

    1.1k GitHub starsUsed in 1 repo~2.6k tokens
    Auto-check passed

Works with

Categories

Questions about Golang Dependency Injection

What does Golang Dependency Injection do?

Dependency injection (DI) in Golang — why DI matters, manual constructor injection, library comparison. Golang Dependency Injection is an agent skill from context-labs/whip. Dependency injection (DI) in Golang — why DI matters, manual constructor injection, library comparison.

When should I use Golang Dependency Injection?

Golang Dependency Injection fits situations like: designing service architecture; wiring dependencies.

How do I install Golang Dependency Injection in Claude Code?

Run `npx skills add context-labs/whip --skill golang-dependency-injection -a claude-code`. Or copy the skill folder (.agents/skills/golang-dependency-injection in context-labs/whip) into .claude/skills/golang-dependency-injection in your project. Claude Code loads it when a task matches its description.

How do I install Golang Dependency Injection in Codex?

Run `npx skills add context-labs/whip --skill golang-dependency-injection -a codex`. Or copy the skill folder (.agents/skills/golang-dependency-injection in context-labs/whip) into .agents/skills/golang-dependency-injection in your project. Codex loads it when a task matches its description.

Can I use Golang Dependency Injection in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add context-labs/whip --skill golang-dependency-injection -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/golang-dependency-injection, .gemini/skills/golang-dependency-injection, .github/skills/golang-dependency-injection and .opencode/skills/golang-dependency-injection in your project.

What does Golang Dependency Injection need to run?

SKILL.md names no scripts, command-line tools or credentials: Golang Dependency Injection is instructions for the agent only. Its frontmatter pre-approves these 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 (from SKILL.md): Designed for Claude Code, Codex or similar harness, and for projects using Golang..

Does Golang Dependency Injection access the network?

SKILL.md names 3 domains. As links in the text: github.com, do.samber.dev and uber-go.github.io. This is read from the text; nothing was executed.

Is Golang Dependency Injection safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Golang Dependency Injection use?

Golang Dependency Injection is published under the MIT licence (declared in SKILL.md). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Golang Dependency Injection use?

About 3.1k tokens (SKILL.md is roughly 12k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 2.4k tokens, read only when the agent opens those files.

What are the alternatives to Golang Dependency Injection?

Skills that share tags, products or a category with Golang Dependency Injection: Context Handling in fp-go (IBM/fp-go, 2k stars), Typed Dependencies with fp-go Effect (IBM/fp-go, 2k stars), fp-go Lenses for Go Structs (IBM/fp-go, 2k stars) and Golang Dependency Injection (samber/cc-skills-golang, 3.4k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Golang Dependency Injection?

context-labs (a GitHub organization) maintains it in context-labs/whip, which has 1,083 GitHub stars. The repository holds 40 skills in this directory. The repository was last updated on October 5, 2026.

Source: context-labs/whip on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.