Golang Google Wire

Samuel BertheCommunityCreated by samberDistributed by Samuel Berthe

Skill
Tool integration
Software development
MIT
No issues found

From the author

Compile-time dependency injection in Golang using google/wire — wire.NewSet, wire.Build, wire.Bind (interface→concrete), wire.Struct, wire.Value, wire.InterfaceValue, wire.FieldsOf, cleanup functions, //go:build wireinject injector files, and generated wire_gen.go. Apply when using or adopting google/wire, when the codebase imports `github.com/google/wire`, or when wiring an application graph at compile time via `wire.Build`. For runtime DI with reflection, see `samber/cc-skills-golang@golang-uber-dig` skill.

— the description by samber

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

google/wire is a code-generation toolkit for dependency injection in Go. Unlike runtime containers that use reflection, wire resolves the dependency graph at compile time and generates plain Go code. This approach ensures that missing dependencies or configuration errors are caught during the build process rather than at runtime. The workflow involves defining provider functions and injector stubs, then running the wire command to generate the final initialization code.

What it does

Resolves complex dependency graphs at compile time
Generates plain Go constructor code without reflection
Supports interface binding and struct field injection
Manages cleanup functions in reverse construction order
Enforces strict type safety for dependency resolution

When to use it

When you want to avoid runtime reflection for dependency injection
When you need to catch dependency errors during compilation
When building Go applications with complex object graphs
When you prefer explicit, generated code over magic runtime containers

Advantages

Zero runtime overhead
Early error detection during build
No magic or hidden runtime behavior
Easy to debug as generated code is standard Go
Supports complex cleanup chains automatically

Usage examples

“Generate the dependency graph for my application.”: The agent runs 'wire ./...' to process injector files and generate the 'wire_gen.go' file containing the necessary constructor calls.
“How do I bind an interface to a concrete implementation in wire?”: The agent provides a 'wire.Bind' example, showing how to map an interface type to a concrete struct provider within a 'wire.NewSet'.
“My application has a cleanup function for the database connection.”: The agent explains how to return a cleanup function from the provider and how wire automatically chains it in reverse order for safe shutdown.

Install

Download the skill as a ZIP:
https://mp-staging.autogineer.com/agent-skills/samber/golang-google-wire/download

Unzip it into the cross-client skills folder of your project:

mkdir -p .agents/skills && unzip golang-google-wire.zip -d .agents/skills

Documentation by samber

Persona: You are a Go architect using wire for compile-time DI. You let the compiler catch missing dependencies, treat wire_gen.go as committed source, and re-run wire ./... after every graph change.

Dependencies:

wire: go install github.com/google/wire/cmd/wire@latest

Using google/wire for Compile-Time Dependency Injection in Go

Code-generation DI toolkit. Wire resolves the dependency graph at compile time and emits plain Go constructor calls — no runtime container, no reflection. Errors appear when you run wire ./..., not at first request.

Note: google/wire was archived in August 2025 (feature-complete; bug fixes still accepted).

Official Resources: pkg.go.dev · github.com/google/wire · User Guide · Best Practices

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.

go get -tool github.com/google/wire/cmd/wire@latest
go get github.com/google/wire

wire vs. Runtime DI

Concern	wire	dig / fx / samber/do
Resolution	Compile time (codegen)	Runtime (reflection)
Error detection	`wire ./...` fails	First `Invoke`/startup
Runtime container	None — plain Go calls	Present
Lifecycle hooks	Not built in	fx: OnStart/OnStop
Generated files	`wire_gen.go` (committed)	None

For lifecycle, lazy loading, and a full matrix see samber/cc-skills-golang@golang-dependency-injection.

Providers

A provider is any Go function — inputs are dependencies, outputs are provided types. Three return forms:

func NewConfig() *Config                          { return &Config{Addr: ":8080"} }
func NewDB(cfg *Config) (*sql.DB, error)          { return sql.Open("postgres", cfg.DSN) }
func NewRedis(cfg *Config) (*redis.Client, func(), error) { // cleanup chained in reverse order
    c := redis.NewClient(&redis.Options{Addr: cfg.RedisAddr})
    return c, func() { c.Close() }, nil
}

Provider Sets

wire.NewSet groups providers for reuse. Sets can reference other sets.

// infra/wire.go
var InfraSet = wire.NewSet(
    NewConfig,
    NewDB,
    NewRedis,
)

// service/wire.go
var ServiceSet = wire.NewSet(
    NewUserRepo,
    NewUserService,
    wire.Bind(new(UserStore), new(*UserRepo)), // interface binding
)

Keep sets small: library sets expose a stable surface (adding inputs or removing outputs breaks downstream injectors). One set per package is a useful default.

Injectors and `//go:build wireinject`

The injector file declares the initialization function. Wire generates its body into wire_gen.go and replaces the stub.

//go:build wireinject

package main

import "github.com/google/wire"

// Wire generates the body of this function.
func InitApp() (*App, func(), error) {
    wire.Build(InfraSet, ServiceSet, NewApp)
    return nil, nil, nil // replaced by codegen
}

The //go:build wireinject tag prevents the stub from being compiled into the binary — only wire_gen.go (which has no such tag) makes it through go build. Without this tag, both files define the same function, causing a compile error.

Alternative syntax when a dummy return is inconvenient:

func InitApp() (*App, func(), error) {
    panic(wire.Build(InfraSet, ServiceSet, NewApp))
}

Interface Bindings

Wire forbids implicit interface satisfaction — you must declare bindings explicitly so the graph is unambiguous when multiple types implement the same interface.

var Set = wire.NewSet(
    NewPostgresUserRepo,
    wire.Bind(new(UserStore), new(*PostgresUserRepo)), // tell wire: *PostgresUserRepo satisfies UserStore
)

Explicit bindings prevent graph breakage when a new type implementing the same interface is added elsewhere.

Struct Providers and Values

wire.Struct fills struct fields from the graph without a manual constructor. Tag fields wire:"-" to exclude them.

wire.Struct(new(Server), "Logger", "DB") // inject named fields
wire.Struct(new(Server), "*")            // inject all non-excluded fields
wire.Value(Foo{X: 42})                   // constant expression (no fn calls / channels)
wire.InterfaceValue(new(io.Reader), os.Stdin) // interface-typed literal
wire.FieldsOf(new(Config), "DSN", "Addr")    // promote struct fields as graph nodes

See advanced.md for the wire:"-" exclusion tag and wire.FieldsOf details.

Disambiguating Duplicate Types

Wire forbids two providers for the same type. Wrap the underlying type in distinct named types so each has exactly one provider:

type PrimaryDSN string
type ReplicaDSN string

Full Application Example

// wire.go — injector, excluded from binary via build tag
//go:build wireinject

package main

func InitApp() (*App, func(), error) {
    wire.Build(config.ConfigSet, infra.InfraSet, service.ServiceSet, NewApp)
    return nil, nil, nil
}

// main.go
func main() {
    app, cleanup, err := InitApp()
    if err != nil { log.Fatal(err) }
    defer cleanup()
    app.Run()
}

Wire generates wire_gen.go (plain Go, committed, DO NOT EDIT). For a full example with per-package sets, cleanup-heavy graphs, and generated output, see recipes.md.

Codegen Workflow

wire ./...           # regenerate all injectors in the module
wire check ./...     # validate graph without regenerating (fast CI check)

Run wire ./... after every constructor signature change. Add //go:generate go run github.com/google/wire/cmd/wire to injector files so go generate ./... also works. Commit wire_gen.go — it must stay in sync for CI builds.

Best Practices

Never edit wire_gen.go — it is overwritten on every wire ./... run. Treat it as a build artifact that happens to be committed; source of truth is the provider and injector files.
Always add //go:build wireinject to injector files — omitting it causes duplicate-symbol compile errors because both the stub and the generated file define the same function.
Use named types to distinguish values of the same underlying type — wire enforces one provider per type; named types like type DSN string let you have PrimaryDSN and ReplicaDSN coexist.
Keep library provider sets minimal and backward-compatible — adding new required inputs breaks downstream injectors; removing outputs does too. Introduce only newly-created types in the same release.
Return (T, func(), error) from cleanup providers and let wire chain them — wire generates the correct reverse-order cleanup and handles partial failures (if construction fails midway, only already-built cleanups run).
Keep injector files focused — one function per file, one package import at a time. Fat injectors with dozens of wire.Build arguments are hard to reason about; delegate to per-package sets.

Common Mistakes

Mistake	Fix
Editing `wire_gen.go` manually	Never edit it. Change providers or injectors and re-run `wire ./...`.
Missing `//go:build wireinject`	Add the tag as the very first line of every injector file.
Two providers returning `*sql.DB`	Wrap with a named struct type: `type PrimaryDB struct { *sql.DB }` — Wire does not distinguish pointer type aliases.
Injecting an interface without `wire.Bind`	Add `wire.Bind(new(MyInterface), new(*MyImpl))` to the provider set.
Forgetting to re-run `wire ./...` after changes	Run wire before `go build`; add it to `go generate` or a Makefile target.
Calling `cleanup()` without guarding for nil	Wire returns nil cleanup on construction error; guard with `if cleanup != nil { defer cleanup() }`.

Testing

Wire generates plain Go constructors, so unit tests use manual injection — no container to clone or reset. For testing patterns (test injectors swapping real providers for fakes, CI stale-check for wire_gen.go), see testing.md.

Cross-References

→ See samber/cc-skills-golang@golang-dependency-injection skill for DI concepts and library comparison
→ See samber/cc-skills-golang@golang-uber-dig skill for runtime reflection-based DI without lifecycle
→ See samber/cc-skills-golang@golang-uber-fx skill for runtime DI with lifecycle hooks, modules, and signal-aware Run()
→ See samber/cc-skills-golang@golang-samber-do skill for generics-based DI without reflection
→ 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

If you encounter a bug or unexpected behavior in google/wire, open an issue at https://github.com/google/wire/issues.

Files

ATTRIBUTION.mdAdded by AutoGineer911 B
LICENSELicence file added by AutoGineer1.0 KiB
SKILL.md10.9 KiB
evals/evals.json15.6 KiB
references/advanced.md7.3 KiB
references/recipes.md6.9 KiB
references/testing.md5.5 KiB

evals/evals.json

[
  {
    "id": 1,
    "name": "build-constraint-on-injector",
    "description": "Tests that the model adds //go:build wireinject to injector files to prevent duplicate-symbol compile errors",
    "prompt": "I'm setting up google/wire in my Go project. Here's my injector file:\n\n```go\npackage main\n\nimport \"github.com/google/wire\"\n\nfunc InitApp() (*App, error) {\n    wire.Build(InfraSet, ServiceSet, NewApp)\n    return nil, nil\n}\n```\n\nWire generates wire_gen.go successfully, but when I run `go build`, I get a 'redeclared in this block' compile error for InitApp. What's wrong and how do I fix it?",
    "trap": "Without the skill, the model may suggest renaming the function, reorganizing packages, or not identify that the missing //go:build wireinject tag is the cause — both the stub and wire_gen.go define InitApp, causing the duplicate.",
    "assertions": [
      {
        "id": "1.1",
        "text": "Identifies the missing //go:build wireinject build tag as the root cause"
      },
      {
        "id": "1.2",
        "text": "Shows //go:build wireinject as the first line of the injector file"
      },
      {
        "id": "1.3",
        "text": "Explains that the tag prevents the stub from being compiled into the binary (only wire_gen.go compiles)"
      },
      {
        "id": "1.4",
        "text": "Does NOT suggest renaming the function or reorganizing packages as the fix"
      },
      {
        "id": "1.5",
        "text": "Does NOT suggest deleting wire_gen.go as the fix"
      }
    ]
  },
  {
    "id": 2,
    "name": "interface-binding-required",
    "description": "Tests that wire.Bind is required for interface-to-concrete mappings and cannot be inferred",
    "prompt": "I have this Go code using google/wire:\n\n```go\n// repo.go\ntype UserStore interface {\n    GetUser(id int64) (*User, error)\n}\n\ntype PostgresUserRepo struct{ db *sql.DB }\nfunc (r *PostgresUserRepo) GetUser(id int64) (*User, error) { ... }\nfunc NewUserRepo(db *sql.DB) *PostgresUserRepo { return &PostgresUserRepo{db: db} }\n\n// service.go\nfunc NewUserService(store UserStore) *UserService { return &UserService{store: store} }\n\n// wire_providers.go\nvar AppSet = wire.NewSet(NewDB, NewUserRepo, NewUserService)\n```\n\nWhen I run `wire ./...` I get: `no provider found for UserStore`. NewUserRepo returns *PostgresUserRepo which clearly implements UserStore. Why doesn't wire figure this out?",
    "trap": "Without the skill, the model might suggest wire should automatically resolve the interface, or suggest wrapping NewUserRepo to return UserStore directly, missing the explicit wire.Bind requirement.",
    "assertions": [
      {
        "id": "2.1",
        "text": "Explains that wire never auto-resolves interface satisfaction — bindings must be explicit"
      },
      {
        "id": "2.2",
        "text": "Shows wire.Bind(new(UserStore), new(*PostgresUserRepo)) added to the provider set"
      },
      {
        "id": "2.3",
        "text": "Places wire.Bind inside the same wire.NewSet (or adds it to a set in wire.Build)"
      },
      {
        "id": "2.4",
        "text": "Explains WHY wire requires explicit bindings (predictability — avoids surprise rebinding when new implementations are added)"
      },
      {
        "id": "2.5",
        "text": "Does NOT suggest changing NewUserRepo to return UserStore directly as the primary fix"
      }
    ]
  },
  {
    "id": 3,
    "name": "duplicate-type-named-wrapper",
    "description": "Tests the named-type pattern to disambiguate multiple values of the same underlying type",
    "prompt": "I'm building a Go service with google/wire. I need to inject two database connection strings — one for the primary database and one for a read replica. I tried this:\n\n```go\nfunc NewPrimaryDSN() string { return os.Getenv(\"PRIMARY_DSN\") }\nfunc NewReplicaDSN() string { return os.Getenv(\"REPLICA_DSN\") }\n\nvar DBSet = wire.NewSet(NewPrimaryDSN, NewReplicaDSN, NewPrimaryDB, NewReplicaDB)\n```\n\nWire complains about multiple bindings for string. How should I structure this?",
    "trap": "Without the skill, the model might suggest using wire.Value or provider arguments, or use a config struct — missing the idiomatic named-type wrapper pattern that wire's own docs recommend.",
    "assertions": [
      {
        "id": "3.1",
        "text": "Introduces distinct named types (e.g., type PrimaryDSN string and type ReplicaDSN string)"
      },
      {
        "id": "3.2",
        "text": "Updates NewPrimaryDSN to return PrimaryDSN and NewReplicaDSN to return ReplicaDSN"
      },
      {
        "id": "3.3",
        "text": "Updates NewPrimaryDB and NewReplicaDB signatures to accept the named types"
      },
      {
        "id": "3.4",
        "text": "Explains that wire enforces one provider per type, so distinct named types are the correct solution"
      },
      {
        "id": "3.5",
        "text": "Does NOT suggest using a single Config struct with both DSNs as the primary fix (that avoids the problem rather than solving it with named types)"
      }
    ]
  },
  {
    "id": 4,
    "name": "cleanup-signature",
    "description": "Tests the (T, func(), error) cleanup provider pattern instead of manual defer in main",
    "prompt": "I'm using google/wire to wire my Go service. I need my *sql.DB connection pool to be closed when the app shuts down. Currently I'm doing this in main:\n\n```go\nfunc main() {\n    app, err := InitApp()\n    if err != nil { log.Fatal(err) }\n    defer db.Close() // but I don't have access to db here!\n    app.Run()\n}\n```\n\nI realize I need the DB closed on shutdown, but InitApp() only returns *App. How should I wire cleanup with google/wire?",
    "trap": "Without the skill, the model might suggest passing db out of InitApp as a second return value, or storing it as a global, missing the (T, func(), error) cleanup provider pattern.",
    "assertions": [
      {
        "id": "4.1",
        "text": "Changes NewDB to return (*sql.DB, func(), error) where the cleanup function calls db.Close()"
      },
      {
        "id": "4.2",
        "text": "Changes the injector function to return (*App, func(), error) to propagate the cleanup chain"
      },
      {
        "id": "4.3",
        "text": "Shows main calling defer cleanup() after the nil-check"
      },
      {
        "id": "4.4",
        "text": "Explains that wire chains cleanup functions and calls them in reverse construction order"
      },
      {
        "id": "4.5",
        "text": "Does NOT suggest passing db as an extra return value from InitApp alongside *App"
      }
    ]
  },
  {
    "id": 5,
    "name": "no-edit-wire-gen",
    "description": "Tests that the model never edits wire_gen.go and instructs re-running wire ./... instead",
    "prompt": "I added a new *Logger parameter to my NewServer constructor in my google/wire project:\n\n```go\nfunc NewServer(db *sql.DB, log *zap.Logger) *Server { ... }\n```\n\nNow `go build` fails with 'too few arguments in call to NewServer'. The error is inside wire_gen.go on line 47. Should I edit wire_gen.go to add the logger argument there, or is there another way?",
    "trap": "Without the skill, a model may suggest editing wire_gen.go directly to 'fix' the build error quickly, which would be overwritten on the next wire run.",
    "assertions": [
      {
        "id": "5.1",
        "text": "Explicitly says NOT to edit wire_gen.go (it is always overwritten)"
      },
      {
        "id": "5.2",
        "text": "Instructs running wire ./... to regenerate wire_gen.go"
      },
      {
        "id": "5.3",
        "text": "Explains that *zap.Logger must be provided in the graph (either via a provider or wire.Value)"
      },
      {
        "id": "5.4",
        "text": "Shows how to add NewLogger (or wire.Value) to the appropriate wire.NewSet so the dependency is satisfied"
      },
      {
        "id": "5.5",
        "text": "Does NOT present editing wire_gen.go as an option"
      }
    ]
  },
  {
    "id": 6,
    "name": "provider-set-organization",
    "description": "Tests per-package provider set organization instead of one giant set in main",
    "prompt": "My Go service using google/wire is growing. I currently have everything in one place:\n\n```go\n// wire.go\n//go:build wireinject\n\nfunc InitApp() (*App, func(), error) {\n    wire.Build(\n        NewConfig, NewDB, NewCache, NewLogger,\n        NewUserRepo, NewOrderRepo, NewProductRepo,\n        wire.Bind(new(UserStore), new(*PostgresUserRepo)),\n        wire.Bind(new(OrderStore), new(*PostgresOrderRepo)),\n        wire.Bind(new(ProductStore), new(*PostgresProductRepo)),\n        NewUserService, NewOrderService, NewProductService,\n        NewHTTPServer, NewRouter,\n        NewApp,\n    )\n    return nil, nil, nil\n}\n```\n\nThis is getting unwieldy. How should I organize this with google/wire?",
    "trap": "Without the skill, the model may just split the providers into helper variables in the same package, missing the idiomatic per-package wire.NewSet pattern.",
    "assertions": [
      {
        "id": "6.1",
        "text": "Introduces per-package wire.NewSet variables (e.g., InfraSet, RepoSet, ServiceSet, TransportSet)"
      },
      {
        "id": "6.2",
        "text": "Each set lives in its own package's wire.go file (not all in main)"
      },
      {
        "id": "6.3",
        "text": "The injector wire.Build references the set variables rather than individual providers"
      },
      {
        "id": "6.4",
        "text": "wire.Bind declarations move into the relevant package's set (not into wire.Build directly)"
      },
      {
        "id": "6.5",
        "text": "Explains the benefit: per-package sets are independently composable and keep the injector readable"
      }
    ]
  },
  {
    "id": 7,
    "name": "injector-parameter-vs-value-provider",
    "description": "Tests using wire.Value or injector parameters for pre-built values instead of wrapper constructors",
    "prompt": "In my Go app using google/wire, I parse a *Config struct from command-line flags in main() before calling InitApp. I tried writing a no-op provider:\n\n```go\nvar parsedCfg *Config\n\nfunc ProvideConfig() *Config { return parsedCfg }\n\nvar AppSet = wire.NewSet(ProvideConfig, ...)\n```\n\nThis works but feels wrong — I'm using a global variable. Is there a cleaner way to pass a pre-built *Config into the wire graph?",
    "trap": "Without the skill, the model might suggest keeping the global variable pattern or using init(), missing both wire.Value and the injector-parameter patterns.",
    "assertions": [
      {
        "id": "7.1",
        "text": "Shows the injector-parameter approach: func InitApp(cfg *Config) (*App, func(), error) with wire.Build"
      },
      {
        "id": "7.2",
        "text": "OR shows wire.Value(cfg) inside wire.Build — both are valid answers"
      },
      {
        "id": "7.3",
        "text": "Explains that injector parameters are treated as pre-built providers by wire"
      },
      {
        "id": "7.4",
        "text": "Does NOT use a global variable as the recommended solution"
      },
      { "id": "7.5", "text": "Does NOT suggest using init() to set the value" }
    ]
  },
  {
    "id": 8,
    "name": "fields-of-struct",
    "description": "Tests wire.FieldsOf to expose struct fields as individual graph nodes",
    "prompt": "I have a single Config struct in my Go app with google/wire:\n\n```go\ntype Config struct {\n    DatabaseDSN  string\n    CacheAddress string\n    APIKey       string\n}\n\nfunc NewConfig() *Config { return loadFromEnv() }\n```\n\nNewDB needs a DatabaseDSN string, NewCache needs a CacheAddress string, NewExternalClient needs an APIKey string — but all three are plain strings. How do I make these available to the wire graph without creating three separate provider functions?",
    "trap": "Without the skill, the model will suggest three named-type wrappers or three extraction functions, missing wire.FieldsOf which promotes struct fields directly.",
    "assertions": [
      {
        "id": "8.1",
        "text": "Uses wire.FieldsOf(new(Config), \"DatabaseDSN\", \"CacheAddress\", \"APIKey\") or a subset"
      },
      {
        "id": "8.2",
        "text": "Places wire.FieldsOf inside the provider set or wire.Build"
      },
      {
        "id": "8.3",
        "text": "Updates NewDB, NewCache, NewExternalClient to accept the string fields as parameters (or uses named types alongside FieldsOf)"
      },
      {
        "id": "8.4",
        "text": "Explains that wire.FieldsOf promotes struct fields as individual graph nodes without manual extraction functions"
      },
      {
        "id": "8.5",
        "text": "Does NOT suggest writing three separate func GetDatabaseDSN(c *Config) string extractor functions as the primary recommendation"
      }
    ]
  },
  {
    "id": 9,
    "name": "test-injector-pattern",
    "description": "Tests the test-injector pattern with wire.Bind for fake dependencies instead of runtime mocking hacks",
    "prompt": "My Go service is wired with google/wire. I have a Mailer interface implemented by SMTPMailer in production. I want integration tests that use a FakeMailer instead — recording sent emails — without modifying the production provider sets. The test must wire the full graph (not just NewUserService in isolation). How should I approach this?",
    "trap": "Without the skill, the model may suggest monkey-patching, a global variable for the mailer, or a runtime DI container for tests — missing the test-injector pattern with a test-only wire.NewSet and wire.Bind.",
    "assertions": [
      {
        "id": "9.1",
        "text": "Creates a test-only provider set (e.g., TestMailerSet) with NewFakeMailer and wire.Bind(new(Mailer), new(*FakeMailer))"
      },
      {
        "id": "9.2",
        "text": "Creates a test injector function in a _test.go file with //go:build wireinject"
      },
      {
        "id": "9.3",
        "text": "The test injector's wire.Build composes the production sets with the test-only set"
      },
      {
        "id": "9.4",
        "text": "Does NOT suggest global variables, monkey-patching, or a runtime DI container for tests"
      },
      {
        "id": "9.5",
        "text": "Mentions that wire ./... (or go generate) must be run to produce the test-injector generated code"
      }
    ]
  },
  {
    "id": 10,
    "name": "wire-vs-fx-for-daemon",
    "description": "Tests that the model recommends uber-go/fx over wire for long-running services that need lifecycle management",
    "prompt": "I'm starting a new Go HTTP server project and evaluating DI options. A colleague suggested google/wire because 'it's simpler and type-safe at compile time.' The server needs graceful shutdown (drain in-flight requests), OnStart/OnStop hooks for the database pool and metrics exporter, and should handle SIGINT/SIGTERM. Should I use wire?",
    "trap": "Without the skill, the model may agree that wire is suitable because it's simple and compile-time safe, not recognizing that lifecycle, signal handling, and hook ordering are exactly what fx provides and wire explicitly lacks.",
    "assertions": [
      {
        "id": "10.1",
        "text": "Identifies that wire has no built-in lifecycle management (no OnStart/OnStop hooks)"
      },
      {
        "id": "10.2",
        "text": "Identifies that wire has no built-in signal handling (SIGINT/SIGTERM)"
      },
      {
        "id": "10.3",
        "text": "Recommends uber-go/fx (or at minimum flags it as the better fit) for a long-running HTTP daemon with lifecycle needs"
      },
      {
        "id": "10.4",
        "text": "Does NOT recommend wire as sufficient for a service requiring graceful shutdown and lifecycle hooks"
      },
      {
        "id": "10.5",
        "text": "Mentions that with wire the developer must implement shutdown and signal handling manually"
      }
    ]
  }
]

Requirements and compatibility

Written for: Claude Code, OpenAI Codex

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Declares allowed tools, Claude Code frontmatter

The author says: Designed for Claude Code, Codex or similar harness, and for projects using Golang.

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by

samber

Publisher

Samuel Berthe (Community)

Distributed by

Samuel Berthe

Source

samber/cc-skills-golang · skills/golang-google-wire · commit bb1d43d

Licence

MIT License (redistribution allowed)

LICENSE (added by AutoGineer from LICENSE)
ATTRIBUTION.md (written by AutoGineer)

Synced

2026-11-08

AutoGineer is not affiliated with or endorsed by samber or Samuel Berthe.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download golang-google-wire.zip