Context Handling in fp-go
IBM/fp-go
Covers handling Go's context.Context idiomatically in fp-go code: reading and scoping context through operators, timeouts, cancellation and converting ctx-first functions.
Dependency injection (DI) in Golang — why DI matters, manual constructor injection, library comparison.
$ npx skills add context-labs/whip --skill golang-dependency-injection -a claude-codeProject install by default; add -g for ~/.claude/skills/.
$ gh skill install context-labs/whip golang-dependency-injection --agent claude-codeProject scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).
$ 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-srcUse ~/.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/
Install the "golang-dependency-injection" agent skill from https://github.com/context-labs/whip/tree/main/.agents/skills/golang-dependency-injection into .claude/skills/golang-dependency-injection/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "golang-dependency-injection", then confirm the skill loads.Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$skill-installer install https://github.com/context-labs/whip/tree/main/.agents/skills/golang-dependency-injectionType this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
$ npx skills add context-labs/whip --skill golang-dependency-injection -a codexProject install goes to .agents/skills/; add -g for ~/.codex/skills/.
$ gh skill install context-labs/whip golang-dependency-injection --agent codexProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/context-labs/whip.git skills-src && mkdir -p .agents/skills && cp -r skills-src/.agents/skills/golang-dependency-injection .agents/skills/golang-dependency-injection && rm -rf skills-srcUse ~/.agents/skills/ instead of .agents/skills for a personal install.
Codex skills documentation · loads skills from .agents/skills/
Install the "golang-dependency-injection" agent skill from https://github.com/context-labs/whip/tree/main/.agents/skills/golang-dependency-injection into .agents/skills/golang-dependency-injection/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "golang-dependency-injection", then confirm the skill loads.Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add context-labs/whip --skill golang-dependency-injection -a cursorProject install goes to .agents/skills/; add -g for ~/.cursor/skills/.
$ gh skill install context-labs/whip golang-dependency-injection --agent cursorProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/context-labs/whip.git skills-src && mkdir -p .cursor/skills && cp -r skills-src/.agents/skills/golang-dependency-injection .cursor/skills/golang-dependency-injection && rm -rf skills-srcUse ~/.cursor/skills/ instead of .cursor/skills for a personal install.
Cursor skills documentation · loads skills from .cursor/skills/, .agents/skills/, .claude/skills/, .codex/skills/
Install the "golang-dependency-injection" agent skill from https://github.com/context-labs/whip/tree/main/.agents/skills/golang-dependency-injection into .cursor/skills/golang-dependency-injection/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "golang-dependency-injection", then confirm the skill loads.Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gemini skills install https://github.com/context-labs/whip.git --path .agents/skills/golang-dependency-injection--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
$ npx skills add context-labs/whip --skill golang-dependency-injection -a gemini-cliProject install goes to .agents/skills/; add -g for ~/.gemini/skills/.
$ gh skill install context-labs/whip golang-dependency-injection --agent gemini-cliProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/context-labs/whip.git skills-src && mkdir -p .gemini/skills && cp -r skills-src/.agents/skills/golang-dependency-injection .gemini/skills/golang-dependency-injection && rm -rf skills-srcUse ~/.gemini/skills/ instead of .gemini/skills for a personal install, then run /skills reload.
Gemini CLI skills documentation · loads skills from .gemini/skills/, .agents/skills/
Install the "golang-dependency-injection" agent skill from https://github.com/context-labs/whip/tree/main/.agents/skills/golang-dependency-injection into .gemini/skills/golang-dependency-injection/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "golang-dependency-injection", then confirm the skill loads.Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gh skill install context-labs/whip golang-dependency-injectionInstalls for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
$ npx skills add context-labs/whip --skill golang-dependency-injection -a github-copilotProject install goes to .agents/skills/; add -g for ~/.copilot/skills/.
$ git clone --depth 1 https://github.com/context-labs/whip.git skills-src && mkdir -p .github/skills && cp -r skills-src/.agents/skills/golang-dependency-injection .github/skills/golang-dependency-injection && rm -rf skills-srcUse ~/.copilot/skills/ instead of .github/skills for a personal install. Commit .github/skills so cloud agent and code review can use it.
GitHub Copilot skills documentation · loads skills from .github/skills/, .claude/skills/, .agents/skills/
Install the "golang-dependency-injection" agent skill from https://github.com/context-labs/whip/tree/main/.agents/skills/golang-dependency-injection into .github/skills/golang-dependency-injection/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "golang-dependency-injection", then confirm the skill loads.GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add context-labs/whip --skill golang-dependency-injection -a opencodeOpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
$ gh skill install context-labs/whip golang-dependency-injection --agent opencodeProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/context-labs/whip.git skills-src && mkdir -p .opencode/skills && cp -r skills-src/.agents/skills/golang-dependency-injection .opencode/skills/golang-dependency-injection && rm -rf skills-srcUse ~/.config/opencode/skills/ instead of .opencode/skills for a personal install.
OpenCode skills documentation · loads skills from .opencode/skills/, .claude/skills/, .agents/skills/
Install the "golang-dependency-injection" agent skill from https://github.com/context-labs/whip/tree/main/.agents/skills/golang-dependency-injection into .opencode/skills/golang-dependency-injection/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "golang-dependency-injection", then confirm the skill loads.OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
golang-dependency-injectionDependency 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. 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.
10 steps, taken from the first numbered list in SKILL.md.
Read from SKILL.md and the folder at commit 8876467. It shows what the files ask for, not the result of running them.
Pre-approves these tools, so the agent can use them without asking each time:
ReadEditWriteGlobGrepBash(go:*)Bash(golangci-lint:*)Bash(git:*)AgentWebFetch…and 3 more on the same allowed-tools line.
From allowed-tools in the SKILL.md frontmatter.
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.
Links to these hosts (documentation or services it may open):
github.comdo.samber.devuber-go.github.ioFrom URLs in SKILL.md, links to its own repository left out.
Names no API keys, tokens, secrets or passwords.
From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
Designed for Claude Code, Codex or similar harness, and for projects using Golang.
From compatibility in the SKILL.md frontmatter.
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.
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.
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.
The full file from context-labs/whip at commit 8876467, republished under its MIT licence (© context-labs). 954 words, ~3,056 tokens.
.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.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:
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-injectionskill takes precedence.
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.
init() for service setupmain() or app startup) — NEVER pass the container as a dependency| Problem without DI | How DI solves it |
|---|---|
| Functions create their own dependencies | Dependencies are injected — swap implementations freely |
| Testing requires real databases, APIs | Pass mock implementations in tests |
| Changing one component breaks others | Loose coupling via interfaces — components don't know each other's internals |
| Services initialized everywhere | Centralized container manages lifecycle (singleton, factory, lazy) |
| All services loaded at startup | Lazy loading — services created only when first requested |
Global state and init() functions | Explicit 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.
For small projects, pass dependencies through constructors. See Manual DI examples for a complete application example.
// ✓ 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 DI breaks down when:
Go has three main approaches to DI libraries:
| Criteria | Manual | google/wire | uber-go/dig + fx | samber/do |
|---|---|---|---|---|
| Project size | Small (< 10 services) | Medium-Large | Large | Any size |
| Type safety | Compile-time | Compile-time (codegen) | Runtime (reflection) | Compile-time (generics) |
| Code generation | None | Required (wire_gen.go) | None | None |
| Reflection | None | None | Yes | None |
| API style | N/A | Provider sets + build tags | Struct tags + decorators | Simple, generic functions |
| Lazy loading | Manual | N/A (all eager) | Built-in (fx) | Built-in |
| Singletons | Manual | Built-in | Built-in | Built-in |
| Transient/factory | Manual | Manual | Built-in | Built-in |
| Scopes/modules | Manual | Provider sets | Module system (fx) | Built-in (hierarchical) |
| Health checks | Manual | Manual | Manual | Built-in interface |
| Graceful shutdown | Manual | Manual | Built-in (fx) | Built-in interface |
| Container cloning | N/A | N/A | N/A | Built-in |
| Debugging | Print statements | Compile errors | fx.Visualize() | ExplainInjector(), web interface |
| Go version | Any | Any | Any | 1.18+ (generics) |
| Learning curve | None | Medium | High | Low |
The dependency graph: Config -> Database -> UserStore -> UserService -> API
Manual:
cfg := NewConfig()
db := NewDatabase(cfg)
store := NewUserStore(db)
svc := NewUserService(store)
api := NewAPI(svc)
api.Run()
// No automatic shutdown, health checks, or lazy loadinggoogle/wire:
// 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 providersuber-go/fx:
app := fx.New(
fx.Provide(NewConfig, NewDatabase, NewUserStore, NewUserService),
fx.Invoke(func(api *API) { api.Run() }),
)
app.Run() // manages lifecycle, but reflection-basedsamber/do:
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 automaticallyDI makes testing straightforward — inject mocks instead of real implementations:
// 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")
}
}Container cloning creates an isolated copy where you override only the services you need to mock:
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).
| Signal | Action |
|---|---|
| < 10 services, simple dependencies | Stay with manual constructor injection |
| 10-20 services, some cross-cutting concerns | Consider a DI library |
| 20+ services, lifecycle management needed | Strongly recommended |
| Need health checks, graceful shutdown | Use a library with built-in lifecycle support |
| Team unfamiliar with DI concepts | Start manual, migrate incrementally |
| Mistake | Fix |
|---|---|
| Global variables as dependencies | Pass through constructors or DI container |
init() for service setup | Explicit initialization in main() or container |
| Depending on concrete types | Accept 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 request | One container per application; use scopes for request-level isolation |
samber/cc-skills-golang@golang-samber-do skill for detailed samber/do usage patternssamber/cc-skills-golang@golang-structs-interfaces skill for interface design and compositionsamber/cc-skills-golang@golang-testing skill for testing with dependency injectionsamber/cc-skills-golang@golang-project-layout skill for DI initialization placement© 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
SKILL.md and 5 other files (references) in .agents/skills/golang-dependency-injection of context-labs/whip.
Open the folder on GitHubat commit 8876467
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.
| Skill | Stars | Used in | Tokens | Auto-check | Licence | Repo updated |
|---|---|---|---|---|---|---|
| Golang Dependency Injection this skillcontext-labs/whip | 1.1k | — | ~3.1k | Automated safety check: Pass | MIT | |
| Context Handling in fp-goIBM/fp-go | 2k | — | ~4.2k | Automated safety check: Pass | Apache-2.0 | |
| Typed Dependencies with fp-go EffectIBM/fp-go | 2k | — | ~4.3k | Automated safety check: Pass | Apache-2.0 | |
| fp-go Lenses for Go StructsIBM/fp-go | 2k | — | ~4.3k | Automated safety check: Pass | Apache-2.0 | |
| Golang Dependency Injectionsamber/cc-skills-golang | 3.4k | — | ~3.2k | Automated safety check: Pass | MIT | |
| Ddd Teaching Skillsazardev/goca | 299 | — | ~5.3k | Automated safety check: Pass | MIT |
IBM/fp-go
Covers handling Go's context.Context idiomatically in fp-go code: reading and scoping context through operators, timeouts, cancellation and converting ctx-first functions.
IBM/fp-go
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.
IBM/fp-go
Generates or hand-writes composable lenses for the fp-go library so nested Go structs can be read and updated immutably.
samber/cc-skills-golang
Comprehensive guide for dependency injection (DI) in Golang.
sazardev/goca
Enseña Domain-Driven Design y Clean Architecture de forma guiada usando Goca CLI.
IBM/fp-go
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.
context-labs/whip
Linting best practices and golangci-lint configuration for Go — running linters, configuring .golangci.yml, nolint suppressions, selecting linters.
context-labs/whip
Golang project layouts and workspaces. An agent skill from context-labs/whip.
context-labs/whip
Golang package/module docs via godig, a pkg.go.dev API client (CLI + MCP) — APIs, symbols, versions, importers, licenses, vulnerabilities.
context-labs/whip
Golang testing with stretchr/testify — assert, require, mock, suite: assertions, mock expectations, argument matchers, suite lifecycle, Eventually, JSONEq.
context-labs/whip
CI/CD with GitHub Actions for Golang — testing, linting, SAST, security scanning, coverage, Dependabot, Renovate, GoReleaser, release pipelines.
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…
Works with
Categories
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.
Golang Dependency Injection fits situations like: designing service architecture; wiring dependencies.
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.
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.
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.
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..
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.
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.
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.
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.
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.
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.