Golang Dependency Injection

Guía de inyección de dependencias en Go con una tabla de decisión según tamaño de proyecto: inyección manual vs. wire, dig/fx o samber/do.

Por samber · samber/cc-skills-golang

Probado · Funciona ★ 9.2/10

Golang Dependency Injection — Guía de inyección de dependencias en Go con una tabla de decisión según tamaño de proyecto: inyección manual vs. wire, dig/fx o samber/do.

Qué hace

Enseña patrones de inyección de dependencias en Go, desde la inyección manual por constructor hasta contenedores basados en librerías (google/wire, uber-go/dig+fx, samber/do), con una tabla de decisión basada en el número de servicios y las necesidades de ciclo de vida. Se activa al diseñar arquitectura de servicios, refactorizar wiring basado en globals/init(), o elegir una librería de DI para Go, y deriva explícitamente a skills hermanas por librería para profundizar.

Informe de la prueba

Le dimos una app Go de 4 servicios conectada con globals e init(): la propia tabla de decisión de la skill (<10 servicios -> mantenerse manual) y su personalidad de 'nunca sobre-diseñar' evitaron que la respuesta recurriera reflexivamente a wire/fx, y produjo un refactor concreto con constructores NewXxx más código de test con mock-boundary que coincidía exactamente con su patrón documentado.

Probado el: 2026-07-13 · Claude Code 2.x (agent harness)

Instalación

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

Comandos y prompts de ejemplo

  • /golang-dependency-injectionGuía de inyección de dependencias en Go con una tabla de decisión según tamaño de proyecto: inyección manual vs. wire, dig/fx o samber/do.

Los skills se activan con peticiones en lenguaje natural, sin comandos que memorizar. Tras instalarlo, prompts como estos lo activan (en inglés):

  • 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