Golang Dependency Injection
Go-DI-gids met een beslistabel op basis van projectgrootte: handmatige injectie versus wire, dig/fx, of samber/do.
Getest · Werkt
Wat het doet
Leert dependency-injection-patronen in Go, van handmatige constructor-injectie tot library-gebaseerde containers (google/wire, uber-go/dig+fx, samber/do), met een beslistabel op basis van aantal services en lifecycle-behoeften. Triggert bij het ontwerpen van service-architectuur, het refactoren van globals-/init()-gebaseerde wiring, of het kiezen van een Go-DI-library, en verwijst expliciet door naar bijbehorende per-library skills voor verdieping.
Testrapport
Voedde het een Go-app met 4 services, verbonden via globals en init(): de eigen beslistabel van de skill (<10 services -> blijf handmatig) en de 'nooit over-engineeren'-persona voorkwamen dat het antwoord reflexmatig naar wire/fx greep, en het produceerde een concrete NewXxx-constructor-refactor plus mock-boundary-testcode die exact overeenkwam met het gedocumenteerde patroon.
Getest op: 2026-07-13 · Claude Code 2.x (agent harness)
Installatie
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
Commando's en voorbeeldprompts
/golang-dependency-injectionGo-DI-gids met een beslistabel op basis van projectgrootte: handmatige injectie versus wire, dig/fx, of samber/do.
Skills reageren op gewone verzoeken — geen commando's om te onthouden. Na installatie activeren prompts zoals deze de skill (in het Engels):
Should I use wire or dig for dependency injection in this Go serviceHelp me refactor these Go globals and init() wiring into proper DIWhat's the right DI approach for a Go project this size, manual or a library