The samber/do v2 container holds a Go application's services in one place, builds each one the first time something asks for it, and shuts them all down in order when the app stops.
WHEN TO USE
SCOPE
USE FOR
Wire a Go application's services into a samber/do dependency-injection container.
Convert manual constructor injection into a samber/do container.
Organize service registration into samber/do packages grouped by module.
Add health checks and graceful shutdown to a samber/do-managed application.
This is a saved copy of the skill's SKILL.md instructions. It may differ from the upstream file or the version you install.
Persona: You are a Go architect setting up dependency injection. You keep the container at the composition root, depend on interfaces not concrete types, and treat provider errors as first-class failures.
Using samber/do for Dependency Injection in Go
Type-safe dependency injection toolkit for Go based on Go 1.18+ generics.
This skill is not exhaustive — refer to library documentation and code examples for more information:
For Go package docs, symbols, versions, importers, and known vulnerabilities, → See samber/cc-skills-golang@golang-pkg-go-dev skill (godig), preferred over Context7 for Go package facts.
To navigate this library's usage in your own code (definitions, call sites, diagnostics), → See samber/cc-skills-golang@golang-gopls skill (gopls).
Context7 remains a fallback for docs not indexed on pkg.go.dev.
Install v2 — v1 is superseded and lacks the generics-based container, scopes, and lifecycle hooks documented below, so v1-era guidance misleads on every API in this skill:
Eager: Created immediately when the container starts
Transient: New instance created on every request
Value: Pre-created value, no instantiation
Provider Functions
Services MUST be registered via provider functions:
type Provider[T any] func(i Injector) (T, error)
Basic Usage
1. Define and Register Services
Follow "Accept Interfaces, Return Structs":
// Register a service (lazy by default)
do.Provide(injector, func(i do.Injector) (Database, error) {
return &PostgreSQLDatabase{connString: "postgres://..."}, nil
})
// Register a pre-created value
do.ProvideValue(injector, &Config{Port: 8080})
// Register a transient service (new instance each time)
do.ProvideTransient(injector, func(i do.Injector) (*Logger, error) {
return &Logger{}, nil
})
// Register an eager service (created immediately at startup)
do.ProvideValue(injector, &Config{Port: 8080})
2. Invoke Services
The container MUST only be accessed at the composition root:
// Invoke with error handling — reserve for call sites outside the DI graph
// (e.g. an HTTP handler that must degrade gracefully instead of crashing)
db, err := do.Invoke[Database](injector)
// MustInvoke panics on error — preferred in providers, recovered by do.Invoke on the parent call
db := do.MustInvoke[Database](injector)
Inside a provider function, always use do.MustInvoke (or MustInvokeAs/MustInvokeNamed/MustInvokeStruct) rather than the error-returning variant:
A provider already returns (T, error), so propagating a dependency failure with do.Invoke costs an extra if err != nil { return nil, err } on every call.
do.MustInvoke panics instead, but samber/do correctly catches and recovers that panic at the enclosing Invoke call and converts it back into a regular error — this recover happens inside the library itself, not in caller code, so MustInvoke is safe to use inside providers.
The failure still surfaces as an error at the composition root, just without the manual boilerplate in every provider.
Depend on interfaces, not concrete types — lets you swap implementations in tests without touching production code
Each service should have one job — services with multiple responsibilities are harder to test and harder to replace
Keep dependency trees shallow — chains beyond 3-4 levels make initialization order fragile and errors harder to trace
Handle errors in provider functions — a silently failing provider creates a broken service that crashes later in unexpected places
Use scopes to organize services by lifecycle — request-scoped services prevent leaks, global services prevent redundant initialization
Use do.MustInvoke* inside provider functions instead of do.Invoke* — samber/do correctly catches and recovers the panic at the outer Invoke call, turning it back into a returned error, so it's safe to use inside providers and you get the same error propagation without the boilerplate
For scopes, lifecycle management, struct injection, and debugging, see Advanced Usage.
For testing patterns (cloning, overrides, mocks), see Testing.
Quick Reference
Registration
Function
Purpose
do.Provide[T]()
Register lazy service (default)
do.ProvideNamed[T]()
Register named lazy service
do.ProvideValue[T]()
Register pre-created value
do.ProvideNamedValue[T]()
Register named value
do.ProvideTransient[T]()
Register new instance each time
do.ProvideNamedTransient[T]()
Register named transient service
do.Package()
Group service registrations
Invocation
Function
Purpose
do.Invoke[T]()
Get service (with error)
do.InvokeNamed[T]()
Get named service
do.InvokeAs[T]()
Get first service matching interface
do.InvokeStruct[T]()
Inject into struct fields using tags
do.MustInvoke[T]()
Get service (panic on error)
do.MustInvokeNamed[T]()
Get named service (panic on error)
do.MustInvokeAs[T]()
Get service by interface (panic on error)
do.MustInvokeStruct[T]()
Inject into struct (panic on error)
Cross-References
→ See samber/cc-skills-golang@golang-dependency-injection skill for DI concepts, comparison, and when to adopt a DI library
→ See samber/cc-skills-golang@golang-structs-interfaces skill for interface design patterns
→ See samber/cc-skills-golang@golang-testing skill for general testing patterns
No requirements beyond installing this skill were found.
Listed as free
Connected services may require an account or charge fees.
Run this outside your AI tool, using Node.js 22.20.0 or newer. Skills CLI 1.7.2 skips skill selection; prompts cancel installation without an interactive terminal. If choosing Project when asked about installation scope, open your project's folder before running this.
Install checklist
Check selected tools if a picker appears; Claude Code may be unchecked under Additional agents. ↑/↓ moves, Space toggles selections, Enter confirms.
Without a tool picker, check Installing to: for your intended tool. Stop if it names a different tool.
If asked, choose Symlink (Recommended) for shared files or Copy to all agents for separate copies; review the summary before confirming installation.
Install the find-skills skill? defaults to Yes, adding another skill for all projects. Choose No if you don't want that extra installation.
Skills CLI 1.7.2 sends install data to skills.sh by default, including the source, skill names, target tools and file details; GitHub sources are reported only when GitHub confirms the repository is public, while other remote sources can also be reported. Confirmed-public GitHub sources also trigger a security-audit request. Before installing, set the environment variable DO_NOT_TRACK=1 or DISABLE_TELEMETRY=1 to disable both.
After installing for Claude Code, open it in the installation project if you chose Project; Global makes the skill available across projects on this computer. Once Claude Code loads the skill, its description helps Claude decide when to use it.
If installation created a top-level skills folder that did not exist when your Claude Code session started, run /reload-skills in that session. Run it again after later changes in that folder.
Install the whole plugin
This route installs the Samber Golang Skills plugin package selected for your AI tool.
Add Samuel's marketplace, then install the plugin
Type both lines inside a Claude Code session, not at your shell prompt. The marketplace is a separate repository of Samuel Berthe's, samber/cc, which also lists his other plugins. The second line opens the details of cc-skills-golang, which carries this repository's 46 Go skills; pick one of the install options shown and Claude Code installs it.
01
/plugin marketplace add samber/cc
02
/plugin install cc-skills-golang@samber
Run it in your terminal. It copies the whole repository, with its 46 skills, into ~/.openclaw/skills/cc-skills-golang, OpenClaw's skills folder in your home folder. To install it for one OpenClaw workspace instead, Samuel gives ~/.openclaw/workspace/skills/cc-skills-golang as the folder.
Run it in your terminal, not inside Gemini CLI; installing from GitHub needs git on your computer. It installs the repository, with its 46 skills, as a Gemini CLI extension. To update it later, run gemini extensions update cc-skills-golang.
Run it in your terminal. It copies the whole repository, with its 46 skills, into ~/.cursor/skills/cc-skills-golang, Cursor's skills folder in your home folder.
Type it in an interactive GitHub Copilot CLI session, not at your shell prompt. It installs the repository straight from GitHub as a plugin, with its 46 skills and no marketplace to add first.
Golang benchmarking, profiling, and performance measurement. Use when writing, running, or comparing Go benchmarks, profiling hot paths with pprof, interpreting CPU/memory/trace profiles, analyzing results with benchstat, setting up CI benchmark regression detection, or investigating production performance with Prometheus runtime metrics. Also use when the developer needs deep analysis on a specific performance indicator - this skill provides the measurement methodology, while samber/cc-skills-golang@golang-performance provides the optimization patterns.Read full description
Golang CLI application development. Use when building, modifying, or reviewing a Go CLI tool — especially for command structure, flag handling, configuration layering, version embedding, exit codes, I/O patterns, signal handling, shell completion, argument validation, and CLI unit testing. Also triggers when code uses cobra, viper, or urfave/cli. For cobra-specific APIs → See samber/cc-skills-golang@golang-spf13-cobra skill; for viper configuration layering → See samber/cc-skills-golang@golang-spf13-viper skill.Read full description
Golang code style conventions — line length and breaking, variable declarations, control flow clarity, when comments help vs hurt. Use when writing or reviewing Go code, asking about style or clarity, or establishing project coding standards. Not for naming conventions (→ See samber/cc-skills-golang@golang-naming skill), linter configuration (→ See samber/cc-skills-golang@golang-lint skill), or doc comments (→ See samber/cc-skills-golang@golang-documentation skill).Read full description
Golang concurrency patterns. Use when writing or reviewing concurrent Go code involving goroutines, channels, select, locks, sync primitives, errgroup, singleflight, worker pools, or fan-out/fan-in pipelines. Also triggers when you detect goroutine leaks, race conditions, channel ownership issues, or need to choose between channels and mutexes.Read full description
Idiomatic context.Context usage in Golang — propagation through API boundaries, cancellation, timeouts and deadlines, request-scoped values, context.WithoutCancel for background work outliving requests. Apply when designing context propagation across layers, debugging leaked or unexpired contexts, choosing between context.Background/TODO/WithoutCancel, or storing values in context. Not for code that merely accepts ctx as first parameter.Read full description
CI/CD pipeline configuration using GitHub Actions for Golang projects — testing, linting, SAST, security scanning, code coverage, Dependabot, Renovate, GoReleaser, code review automation, and release pipelines. Use when setting up or improving Go project CI, configuring GitHub Actions workflows, adding linters or security scanners, automating dependency updates, or adding quality gates.Read full description
