Comprehensive guide for dependency injection (DI) in Golang. Covers why DI matters (testability, loose coupling, separation of concerns, lifecycle management), manual constructor injection, and DI library comparison (google/wire, uber-go/dig, uber-go/fx, samber/do). Use this skill when designing service architecture, setting up dependency injection, refactoring tightly coupled code, managing singletons or service factories, or when the user asks about inversion of control, service containers, or wiring dependencies in Go. For a specific DI library, → See `samber/cc-skills-golang@golang-google-wire`, `samber/cc-skills-golang@golang-uber-dig`, `samber/cc-skills-golang@golang-uber-fx`, or `samber/cc-skills-golang@golang-samber-do` skills.
87
82%
Does it follow best practices?
Impact
100%
1.01xAverage score across 3 eval scenarios
Passed
No known issues
Quality
Discovery
100%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is an excellent skill description that covers all key dimensions thoroughly. It provides specific capabilities, rich trigger terms that developers would naturally use, explicit 'Use when' guidance with multiple scenarios, and clear cross-references to related but distinct skills. The description is comprehensive without being padded, and uses proper third-person voice throughout.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions and topics: testability, loose coupling, separation of concerns, lifecycle management, manual constructor injection, and DI library comparison with four named libraries. | 3 / 3 |
Completeness | Clearly answers both 'what' (comprehensive guide covering DI concepts, manual injection, library comparison) and 'when' (explicit 'Use this skill when...' clause with multiple trigger scenarios). Also includes cross-references to related skills for specific libraries. | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural terms users would say: 'dependency injection', 'DI', 'Golang', 'Go', 'testability', 'loose coupling', 'inversion of control', 'service containers', 'wiring dependencies', 'singletons', 'service factories', 'refactoring tightly coupled code'. These are terms developers naturally use. | 3 / 3 |
Distinctiveness Conflict Risk | Clearly scoped to dependency injection in Go specifically, with explicit delineation from the individual library-specific skills via cross-references. The niche is well-defined and unlikely to conflict with other skills. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
64%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a solid, comprehensive DI guide for Go with strong actionability — executable code examples, a well-structured comparison table, and clear testing patterns. Its main weaknesses are moderate verbosity (explaining DI fundamentals Claude already knows, some redundancy between best practices and common mistakes) and a lack of explicit step-by-step migration workflows with validation checkpoints for the refactor mode. The progressive disclosure structure is reasonable but unverifiable without bundle files.
Suggestions
Remove or significantly condense the 'Why Dependency Injection?' table — Claude already understands DI concepts; a single sentence suffices.
Add an explicit step-by-step migration workflow for refactor mode with validation checkpoints (e.g., 'run tests after each extraction step'), since refactoring DI is a multi-step process where errors compound.
Consolidate the 'Common Mistakes' table into the 'Best Practices Summary' to reduce redundancy — most mistakes are just inversions of the best practices.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is generally well-structured but includes some unnecessary content like the 'Why Dependency Injection?' table explaining basic DI concepts Claude already knows, and the 'Common Mistakes' table which largely restates the best practices. The comparison tables and code examples earn their place, but the overall document could be tightened by ~20-30%. | 2 / 3 |
Actionability | The skill provides fully executable Go code examples for manual DI, all four library approaches with the same dependency graph, and complete testing examples with mocks. The decision table gives concrete criteria for choosing an approach, and the code is copy-paste ready. | 3 / 3 |
Workflow Clarity | The refactor mode describes a parallel sub-agent approach which is interesting but lacks explicit validation checkpoints or a step-by-step migration workflow. The 'When to Adopt a DI Library' table provides decision guidance, but there's no explicit sequence for migrating from manual DI to a library, and the refactor mode's consolidation step is vague. | 2 / 3 |
Progressive Disclosure | The skill references several external files (./references/manual-di.md, ./references/google-wire.md, etc.) and cross-references other skills, which is good structure. However, no bundle files were provided, so we can't verify these references exist. The main document itself is quite long with inline content (comparison tables, testing examples) that could potentially be split out, though the inline content is reasonably well-organized with clear headers. | 2 / 3 |
Total | 9 / 12 Passed |
Validation
81%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 9 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
metadata_field | 'metadata' should map string keys to string values | Warning |
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 9 / 11 Passed | |
8c7e016
Table of Contents
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.