Skip to content
skillsafebeta
← Report library
Purpose / Development

Golang Google Wire Skill Security Audit

What the author says it does (original text)

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 c

Independent security check

Security risks found

Files checked
5
Risks found
3
Could it run dangerous commands?Looks for programs run straight after downloading, remote control of your computer, and hidden commands.Risks found: 1
Medium risk

Installation uses the mutable `@latest` tool version

Source references: 4
What we found

The Skill directs installation and use of `github.com/google/wire/cmd/wire@latest` instead of a reviewed, fixed version; the same document notes that the project is archived. What resolves as “latest” later may differ from what the Skill author tested.

Why this matters

The installation retrieves code from the network and compiles a local tool that is then used to rewrite project source. Upstream releases, dependency changes, or a supply-chain compromise could therefore change both executed code and generated output.

Both the installation metadata and instructions use `@latest`, so separate installs may retrieve different executable code that was not pinned and validated with this Skill. The note that the project is archived does not remove this supply-chain and reproducibility risk. A user can ask for a specific tested version and verification method, and can block automatic installation or inspect the resolved version first.

SKILL.md:31In the instructionsOpen original file
- wire: `go install github.com/google/wire/cmd/wire@latest`
Show 3 other places
SKILL.md:37In the instructionsOpen original file
Note: `google/wire` was archived in August 2025 (feature-complete; bug fixes still accepted).
SKILL.md:47In the instructionsOpen original file
```bashgo get -tool github.com/google/wire/cmd/wire@latestgo get github.com/google/wire```
SKILL.md:17In the instructionsOpen original file
        - wire    install:      - kind: go        package: github.com/google/wire/cmd/wire@latest        bins: [wire]    skill-library-version: "0.7.0"
Could it expose your files or keys?Looks for uploads of files containing passwords or keys, and keys written directly in the code.No risks found
Could it delete files or keep running?Looks for broad file deletion, disk overwrites, and programs set to start automatically.Risks found: 1
Medium risk

Module-wide generation overwrites source files that are meant to be committed

Source references: 4
What we found

The Skill requires `wire ./...` after graph changes. This overwrites generated `wire_gen.go` files across the module; the documentation explicitly says those files are overwritten and should be committed. The scope is the entire module rather than one confirmed injector.

Why this matters

Local content in existing generated files can be lost, and persistent changes may be produced across multiple packages. If the generator version or selected build tags are unexpected, those changes can enter commits and later builds.

This is legitimate Wire behavior, but `wire ./...` explicitly regenerates every injector in the module and overwrites generated files, which the Skill then expects to be committed. In a repository with uncommitted work or several injectors, it can create broad source diffs or replace manual changes in generated files. A user can require inspection of the worktree and target injectors first, narrow the command scope, and review changes before any commit.

SKILL.md:190In the instructionsOpen original file
```bashwire ./...           # regenerate all injectors in the modulewire check ./...     # validate graph without regenerating (fast CI check)```
Show 3 other places
SKILL.md:194In the instructionsOpen original file
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.
SKILL.md:198In the instructionsOpen original file
1. 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.2. 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.
SKILL.md:189In the instructionsOpen original file
```bashwire ./...           # regenerate all injectors in the modulewire check ./...     # validate graph without regenerating (fast CI check)```
Could it bypass safety checks?Looks for skipped website security checks, excessive file access, or actions that skip your approval.Risks found: 1
Medium risk

Declared permissions are substantially broader than Wire setup requires

Source references: 1
What we found

The `allowed-tools` entry permits unrestricted file editing, all `git:*` commands, agents, and web access, while the core task mainly needs edits to relevant Go files and Wire execution. `git:*` is not limited to read-only commands, so it also covers Git operations capable of changing remotes or discarding local work.

Why this matters

If the host enforces this list as authorization, an erroneous instruction or untrusted content could modify unrelated files, alter Git history or remote repository state, or expose project material through agent or web tools. The evidence shows granted capability, not that such an action occurred.

The Skill declares file read/write access plus unrestricted `git:*`, agent, and web access. Git mutations and agent calls are not inherently required for Wire code generation. This declaration does not prove those capabilities will be used, but it expands potential exposure of local work, repository remotes, and network-derived content. A user can ask the author to restrict Git to read-only commands and disable Agent, WebFetch, and unnecessary write access at runtime.

SKILL.md:22In the instructionsOpen original file
    skill-library-version: "0.7.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(wire:*) Bash(godig:*) Bash(gopls:*) LSP mcp__gopls__*paths:
Could it mislead the AI or hide text?Checks the skill instructions for requests to ignore you, influence the report, or hide text in invisible characters.No risks found
Could it change links or payment recipients without asking?Looks for forced referral or payment changes combined with instructions to hide the change.No risks found

Inside this skill

8 instruction sections

The Skill uses Google Wire to resolve dependency graphs before compilation and generate ordinary Go constructor code; it is not a runtime DI container.

View source
SKILL.md:35In the instructionsOpen original file
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.

It instructs users to exclude injector stubs from normal builds with the `wireinject` build tag and use the generated `wire_gen.go`.

View source
SKILL.md:101In the instructionsOpen original file
The injector file declares the initialization function. Wire generates its body into `wire_gen.go` and replaces the stub.
SKILL.md:117In the instructionsOpen original file
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.

Its routine workflow regenerates injectors across the Go module and directs users to commit the generated files.

View source
SKILL.md:189In the instructionsOpen original file
```bashwire ./...           # regenerate all injectors in the modulewire check ./...     # validate graph without regenerating (fast CI check)```
SKILL.md:194In the instructionsOpen original file
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.
Start here · InstructionsSKILL.md
golang-google-wire
Lines connect the instruction file to its sections, not an observed execution order. Select a section to read the source. 6 more sections are available in the original file.

File reference map

References: 3
Files making referencesReferenced content
Lines show actual file references, not execution order. Select a node to highlight its connections and inspect the files and source locations. Dashed lines include files that still need locating.
Files and check records5 files

Coverage and gaps

Content covered in each file

These are the source ranges included in this check, not a guarantee that every issue has been resolved.

  • SKILL.mdFull text included
  • references/advanced.mdFull text included
  • references/recipes.mdFull text included
  • references/testing.mdFull text included
  • evals/evals.jsonFull text included

This report is for the version above. We read the available code and instructions without running the skill or checking extra packages it installs. This is not a promise of safety: a different version or setup may behave differently.

  • SKILL.mdInstructions
  • evals/evals.jsonSupporting file
  • references/advanced.mdSupporting file
  • references/recipes.mdSupporting file
  • references/testing.mdSupporting file

Operations mentioned in code and instructions

Connect to websites
SKILL.md:12In the instructionsOpen original file
    emoji: "🪡"    homepage: https://github.com/samber/cc-skills-golang    requires:
SKILL.md:39In the instructionsOpen original file
**Official Resources:** [pkg.go.dev](https://pkg.go.dev/github.com/google/wire) · [github.com/google/wire](https://github.com/google/wire) · [User Guide](https://github.com/google/wire/blob/main/docs/guide.md) · [Best Practices](https://github.com/google/wire/blob/main/docs/best-practices.md)
SKILL.md:235In the instructionsOpen original file
If you encounter a bug or unexpected behavior in google/wire, open an issue at <https://github.com/google/wire/issues>.
Run commands
SKILL.md:22In the instructionsOpen original file
    skill-library-version: "0.7.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(wire:*) Bash(godig:*) Bash(gopls:*) LSP mcp__gopls__*paths:
SKILL.md:47In the instructionsOpen original file
```bashgo get -tool github.com/google/wire/cmd/wire@latest
SKILL.md:189In the instructionsOpen original file
```bashwire ./...           # regenerate all injectors in the module
Read files
SKILL.md:70In the instructionsOpen original file
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
references/advanced.md:24In the instructionsOpen original file
func NewDB(cfg *Config) (*sql.DB, func(), error) {    db, err := sql.Open("postgres", string(cfg.DSN))    if err != nil { return nil, nil, err }
references/recipes.md:63In the instructionsOpen original file
func NewDB(cfg *config.Config) (*sql.DB, func(), error) {    db, err := sql.Open("postgres", cfg.DSN)    if err != nil { return nil, nil, err }
Read keys or account settings
evals/evals.json:64In the instructionsOpen original file
    "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.",
evals/evals.json:206In the instructionsOpen original file
    "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.",
evals/evals.json:211In the instructionsOpen original file
        "id": "8.1",        "text": "Uses wire.FieldsOf(new(Config), \"DatabaseDSN\", \"CacheAddress\", \"APIKey\") or a subset"      },
Lines read
1,193
File checksum (to compare versions)
83e6fe593c76e123e05e7c76e2f71aa35d6c6ed4a9ec2cfb1bddc128b35130b3