Golang Uber DigSAFE
๐ง๐จ A collection of Golang agentic skills that works
Overview
๐ง๐จ A collection of Golang agentic skills that works
3823d8ae0038OBSERVED ยท 2026-10-08Host compatibility
What the documentation claims. We have not run a compatibility test.
| Host | Status | Notes |
|---|---|---|
| claude-code | mentioned | |
| codex | mentioned | |
| openclaw | mentioned |
What it tells the agent
The instruction file, verbatim from the audited commit โ this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.
---
name: golang-uber-dig
description: "Implements dependency injection in Golang using uber-go/dig โ reflection-based container, Provide/Invoke, dig.In/dig.Out parameter and result objects, named values, value groups, optional dependencies, scopes, and Decorate. Apply when using or adopting uber-go/dig, when the codebase imports `go.uber.org/dig`, or when wiring an application graph at startup. For higher-level lifecycle and modules, see `samber/cc-skills-golang@golang-uber-fx` skill."
user-invocable: true
license: MIT
compatibility: Designed for Claude Code, Codex or similar harness, and for projects using Golang.
metadata:
author: samber
version: "1.2.2"
openclaw:
emoji: "โ"
homepage: https://github.com/samber/cc-skills-golang
requires:
bins:
- go
install: []
skill-library-version: "1.19.0"
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 Bash(godig:*) Bash(gopls:*) LSP mcp__gopls__*
paths:
- "**/*.go"
---
**Persona:** You are a Go architect wiring an application graph with dig. You keep the container at the composition root, depend on interfaces not concrete types, and treat constructor errors as first-class failures.
# Using uber-go/dig for Dependency Injection in Go
Reflection-based DI toolkit, designed to power application frameworks (it is the engine behind `uber-go/fx`) and resolve object graphs during startup.
**Official Resources:**
- [pkg.go.dev/go.uber.org/dig](https://pkg.go.dev/go.uber.org/dig)
- [github.com/uber-go/dig](https://github.com/uber-go/dig)
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.
```bash
go get go.uber.org/dig
```
## dig vs. fx
fx is built on dig and shares the same container engine โ the DI primitives (`Provide`, `Invoke`, `In`/`Out` structs, named values, value groups) are identical. `fx.In`/`fx.Out` are re-exports of `dig.In`/`dig.Out`.
What fx adds on top of dig:
| Concern | dig | fx |
| --- | --- | --- |
| DI container | โ
`dig.New()` | โ
(embedded) |
| Lifecycle hooks | โ | โ
`fx.Lifecycle` OnStart/OnStop |
| Module system | โ | โ
`fx.Module` with scoped decorators |
| Signal-aware run loop | โ | โ
`app.Run()` blocks on SIGINT/SIGTERM |
| Structured event logging | โ | โ
`fx.WithLogger` / `fxevent` |
| Startup/shutdown timeout | โ | โ
`fx.StartTimeout` / `fx.StopTimeout` |
**Choose dig** when you need the wiring graph only: CLI tools, libraries exposing a container to callers, test harnesses, or embedding DI into an existing app that manages its own lifecycle.
**Choose fx** for long-running services (HTTP servers, workers, daemons) โ lifecycle and signal handling are non-negotiable there. See `samber/cc-skills-golang@golang-uber-fx` skill.
## Container
```go
import "go.uber.org/dig"
c := dig.New()
```
Useful options: `dig.DeferAcyclicVerification()` (faster startup), `dig.RecoverFromPanics()` (turn panics into `dig.PanicError`), `dig.DryRun(true)` (validate without invoking).
## Provide and Invoke
```go
// Register a constructor โ lazy, only runs when its output is needed
err := c.Provide(func(cfg *Config) (*sql.DB, error) {
return sql.Open("postgres", cfg.DSN)
})
// Pull a service out of the container by asking for it as a function parameter
err = c.Invoke(func(db *sql.DB) error {
return db.Ping()
})
```
Constructors are **lazy** and **memoized**: each output type is built once and shared (singleton per container). `Provide` errors at registration if the constructor is malformed; `Invoke` returns the constructor's error wrapped with the dependency path that triggered it.
A dig constructor is any function whose inputs are dependencies and whose outputs are provided types. `error` (last return) signals construction failure. Follow "accept interfaces, return structs".
## Parameter Objects with `dig.In`
Once a constructor has 4+ dependencies, embed `dig.In` to group them as struct fields and tag fields:
```go
type HandlerParams struct {
dig.In
Logger *zap.Logger
DB *sql.DB
Cache *redis.Client `optional:"true"` // zero value if not provided
DBRO *sql.DB `name:"readonly"` // named dependency
Routes []http.Handler `group:"routes"` // value group
}
func NewHandler(p HandlerParams) *Handler { /* ... */ }
```
Tags: `name:"..."`, `optional:"true"`, `group:"..."`.
## Result Objects with `dig.Out`
Return several values from one constructor and attach `name`/`group` tags to results:
```go
type ConnResult struct {
dig.Out
ReadWrite *sql.DB `name:"primary"`
ReadOnly *sql.DB `name:"readonly"`
}
func NewConnections(cfg *Config) (ConnResult, error) { /* ... */ }
```
## Named Values
Two providers of the same type collide. Disambiguate with `dig.Name`:
```go
c.Provide(NewPrimaryDB, dig.Name("primary"))
c.Provide(NewReadOnlyDB, dig.Name("readonly"))
```
Consume by adding `name:"primary"` / `name:"readonly"` to a `dig.In` field.
## Value Groups
Many providers, one consumer slice โ typical for HTTP handlers, health checks, migrations:
```go
type RouteResult struct {
dig.Out
Handler http.Handler `group:"routes"`
}
func NewUserHandler(db *sql.DB) RouteResult { /* ... */ }
func NewPostHandler(db *sql.DB) RouteResult { /* ... */ }
type ServerParams struct {
dig.In
Routes []http.Handler `group:"routes"`
}
```
**Flatten** โ append `,flatten` (e.g. `group:"routes,flatten"`) to unwrap a slice instead of nesting it. Group oTrust audit
SAFEgrade B ยท trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.
| Layer | What it checks | Result |
|---|---|---|
| L0 | Provenance & inventory | PASS |
| L1 | Static analysis of the code | NA |
| L2 | Instruction surface (what it tells the agent) | PASS |
| L3 | Class-specific surface | PASS |
| L4 | Behavioural (sandbox) | SKIPPED |
What the source does
- Filesystem
- none-observed
- Network
- none-observed
- Shell
- none-observed
- Dependencies
- pinned
- Secrets in source
- none-found
Findings (0)
No findings outside the package's declared scope.
Gates applied: no_behavioural_pass.
3823d8ae0038full audit observations/trust-audit/skill/samber__golang-uber-dig.json ยท Report an issue / request a re-scanAudit history
Every audit this skill has had.
| Date | Source | Verdict | Grade | Score | Change |
|---|---|---|---|---|---|
| 2026-10-08 | 3823d8ae0038 | SAFE | B | 89 | first audit |
Questions
What does the Golang Uber Dig skill do?
๐ง๐จ A collection of Golang agentic skills that works
Is Golang Uber Dig safe to install?
The audit found nothing in the source that contradicts what it says it does, and graded it B (89/100). Grade A is held back for packages that have also passed a sandboxed behavioural run, which is why a clean skill reads B.
What can Golang Uber Dig access on my machine?
The audit observed no filesystem, network or shell use at all in its source.
Which assistants does Golang Uber Dig work with?
Its documentation mentions claude-code, codex and openclaw. That is what the text claims, not a compatibility test we ran.
How current is this page?
The grade is for one exact copy of the source (3823d8ae0038), read on 2026-10-08. The repository is watched, and a new audit runs when it changes โ this is the first audit.