golang-dependency-injection
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.
87
82%
Does it follow best practices?
Impact
99%
1.05xAverage 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 clearly articulates what the skill covers (DI concepts, manual injection, specific library comparisons), includes an explicit 'Use this skill when...' clause with diverse trigger scenarios, and uses natural keywords that users would employ. The description is specific to Go/Golang dependency injection, making it highly distinctive and unlikely to conflict with other skills.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions and topics: manual constructor injection, DI library comparison with named libraries (google/wire, uber-go/dig, uber-go/fx, samber/do), testability, loose coupling, separation of concerns, lifecycle management. | 3 / 3 |
Completeness | Clearly answers both 'what' (comprehensive guide covering DI concepts, manual injection, library comparison) and 'when' with an explicit 'Use this skill when...' clause listing multiple trigger scenarios. | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural terms: 'dependency injection', 'DI', 'Golang', 'Go', 'service architecture', 'refactoring tightly coupled code', 'singletons', 'service factories', 'inversion of control', 'service containers', 'wiring dependencies'. These are terms users would naturally use. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive — targets a specific niche (dependency injection in Go) with named libraries and Go-specific terminology. Unlikely to conflict with general coding skills or other language-specific 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 skill with excellent actionability — the side-by-side code comparisons across four approaches and the decision table are particularly valuable. The main weaknesses are moderate verbosity (explaining DI concepts Claude already knows, redundant tables) and a refactoring workflow that lacks explicit validation checkpoints. The progressive disclosure structure is reasonable but the main file carries too much inline content that could be offloaded to the referenced files.
Suggestions
Remove or significantly condense the 'Why Dependency Injection?' table — Claude already understands these concepts; a single sentence suffices.
Add explicit validation steps to the Refactor mode workflow (e.g., 'verify compilation after each migration step, run existing tests to confirm no regressions').
Move the 'Common Mistakes' table and 'Testing with DI' section to reference files to reduce the main skill's token footprint.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is generally well-structured but includes some unnecessary content like the 'Why Dependency Injection?' table explaining concepts Claude already understands, and the verbose 'Common Mistakes' table that largely restates the best practices. The comparison table and quick comparison section are valuable but could be tighter. | 2 / 3 |
Actionability | The skill provides fully executable Go code examples throughout — manual DI constructors, good/bad patterns, all four library approaches with the same dependency graph, mock testing examples, and samber/do container cloning. Code is copy-paste ready with realistic signatures. | 3 / 3 |
Workflow Clarity | The skill defines two modes (Design and Refactor) with clear steps, and the decision table provides a clear path for choosing an approach. However, the Refactor mode's sub-agent workflow lacks validation checkpoints — there's no explicit step to verify the migration succeeded or that the refactored code compiles/passes tests. The adoption signals table helps but the actual migration workflow is underspecified. | 2 / 3 |
Progressive Disclosure | The skill references several external files (./references/manual-di.md, ./references/google-wire.md, ./references/uber-dig-fx.md, ./references/samber-do.md) and cross-references other skills, which is good structure. However, no bundle files were provided, so these references cannot be verified. The main file itself is quite long (~200+ lines) with substantial inline content (the full comparison table, testing examples, common mistakes) that could have been split into reference files. | 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 | |
- Repository
- samber/cc-skills-golang
- Commit
e9761db
- Reviewed
Table of Contents
Is this your skill?
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.