
Golang Uber Fx
Wire long-running Go services with uber-go/fx modules, lifecycle hooks, and composition-root patterns instead of ad-hoc init() spaghetti.
Overview
golang-uber-fx is an agent skill for the Build phase that guides uber-go/fx application wiring, modules, lifecycle hooks, and signal-aware Run() in Go services.
Install
npx skills add https://github.com/samber/cc-skills-golang --skill golang-uber-fxWhat is this skill?
- Covers fx.New, fx.Provide, fx.Invoke, fx.Module, and signal-aware Run()
- Documents fx.Annotate (name/group/As), fx.Decorate, fx.Supply, fx.Replace, fx.WithLogger
- Pushes lifecycle into hooks instead of init() at the composition root
- Pairs with golang-uber-dig skill for raw DI without lifecycle when needed
- Allowed tools include go, golangci-lint, git, Context7 docs, and repo edit/bash
- Skill library version 1.24.0 in metadata
- Documented skill version 1.1.0
Adoption & trust: 1.9k installs on skills.sh; 2k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your Go service needs dependable startup/shutdown and modular DI but init() and manual wiring obscure dependencies and testability.
Who is it for?
Solo builders shipping Go APIs or workers that already use or are adopting go.uber.org/fx.
Skip if: Projects using only raw dig without lifecycle, or teams wanting a non-Go DI framework.
When should I use this skill?
Using or adopting uber-go/fx, imports of go.uber.org/fx, or wiring services with fx.New.
What do I get? / Deliverables
You get an fx-centered graph at the composition root with modules, hooks, and annotations aligned to uber-go/fx patterns ready for lint and go test verification.
- Refactored fx graph and modules
- Lifecycle hook implementations
- Composition-root wiring changes
Recommended Skills
Journey fit
How it compares
Fx application framework skill—pair with golang-uber-dig when you need container mechanics without the fx lifecycle layer.
Common Questions / FAQ
Who is golang-uber-fx for?
Go-focused solo and indie developers wiring long-running services with uber-go/fx in Claude Code, Cursor, or Codex.
When should I use golang-uber-fx?
Use it in Build/backend when the codebase imports go.uber.org/fx or you are adopting fx.New, modules, lifecycle hooks, or Annotate/Decorate patterns.
Is golang-uber-fx safe to install?
See the Security Audits panel on this Prism page; the skill may run go, golangci-lint, git, and edit repository files per allowed-tools.
Workflow Chain
Then invoke: skill samber cc skills golang golang uber dig
SKILL.md
READMESKILL.md - Golang Uber Fx
**Persona:** You are a Go architect building a long-running service with fx. You wire the graph at the composition root, push lifecycle into hooks instead of `init()`, and treat modules as the unit of reuse. # Using uber-go/fx for Application Wiring in Go Application framework combining a reflection-based DI container (built on `uber-go/dig`) with a lifecycle, module system, signal-aware run loop, and structured event logging. For long-running services where boot order, graceful shutdown, and modular composition matter. **Official Resources:** - [pkg.go.dev/go.uber.org/fx](https://pkg.go.dev/go.uber.org/fx) - [uber-go.github.io/fx](https://uber-go.github.io/fx/) - [github.com/uber-go/fx](https://github.com/uber-go/fx) This skill is not exhaustive. Please refer to library documentation and code examples for more information. Context7 can help as a discoverability platform. ```bash go get go.uber.org/fx ``` ## fx vs. dig fx is built on top of dig and shares the same reflection-based 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: | 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 fx** for long-running services (HTTP servers, workers, daemons) — lifecycle and signal handling are mandatory there, and modules make large service graphs manageable. **Choose raw dig** when you need wiring without a framework: CLI tools, libraries that expose a container to callers, test harnesses, or embedding DI into an existing app that manages its own lifecycle. See `samber/cc-skills-golang@golang-uber-dig` skill. ## The Application ```go import "go.uber.org/fx" app := fx.New( fx.Provide(NewLogger, NewDatabase, NewServer), fx.Invoke(RegisterRoutes), ) app.Run() // blocks until SIGINT/SIGTERM, then runs OnStop hooks ``` Boot stages: `fx.New` validates types (constructors do not run); `app.Start(ctx)` runs each `fx.Invoke` and fires OnStart hooks in topological order; main blocks on `app.Done()`; `app.Stop(ctx)` fires OnStop hooks in reverse order. Default timeout is **15 seconds** — override with `fx.StartTimeout` / `fx.StopTimeout`. ## Provide and Invoke ```go fx.New( fx.Provide(NewLogger, NewDatabase, NewServer), // lazy fx.Invoke(RegisterRoutes, StartMetricsExporter), // always run during Start ) ``` `fx.Provide` registers constructors; `fx.Invoke` is the trigger — without an Invoke (directly or transitively) referencing a type, its constructor never runs. ## Lifecycle Hooks Inject `fx.Lifecycle` and append hooks. Constructors sh