Golang Dependency Injection

Go-DI-Leitfaden mit Projektgrößen-Entscheidungstabelle für manuelle Injection vs. wire, dig/fx oder samber/do.

Getestet · Funktioniert ★ 9.2/10

Was es kann

Vermittelt Dependency-Injection-Muster in Go, von manueller Constructor-Injection bis zu bibliotheksbasierten Containern (google/wire, uber-go/dig+fx, samber/do), mit einer Entscheidungstabelle anhand von Service-Anzahl und Lifecycle-Bedarf. Reagiert beim Entwurf von Service-Architekturen, beim Refactoring von globals-/init()-basierter Verdrahtung oder bei der Wahl einer Go-DI-Bibliothek und verweist explizit an Sibling-Skills für einzelne Bibliotheken zur Vertiefung.

Testbericht

Gefüttert mit einer 4-Service-Go-App, verdrahtet mit globals und init(): Die eigene Entscheidungstabelle des Skills (<10 Services -> manuell bleiben) und die Persona „nie überengineeren“ hielten die Antwort davon ab, reflexartig zu wire/fx zu greifen, und lieferte einen konkreten NewXxx-Constructor-Refactor plus Mock-Boundary-Testcode, der exakt dem dokumentierten Muster entspricht.

Getestet am: 2026-07-13 · Claude Code 2.x (agent harness)

Installation

git clone https://github.com/samber/cc-skills-golang
cd cc-skills-golang
mkdir -p ~/.claude/skills
cp -r skills/golang-dependency-injection ~/.claude/skills/golang-dependency-injection

Befehle & Beispiel-Prompts

/golang-dependency-injectionGo-DI-Leitfaden mit Projektgrößen-Entscheidungstabelle für manuelle Injection vs. wire, dig/fx oder samber/do.

Skills reagieren auf normale Anfragen — keine Slash-Befehle nötig. Nach der Installation aktivieren Prompts wie diese den Skill (auf Englisch):

Should I use wire or dig for dependency injection in this Go service
Help me refactor these Go globals and init() wiring into proper DI
What's the right DI approach for a Go project this size, manual or a library

Vollständiger Testbericht (Englisch) →