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.
89
86%
Does it follow best practices?
Impact
100%
1.00xAverage 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 dimensions well. It provides specific capabilities, includes a comprehensive set of natural trigger terms, explicitly states both what the skill does and when to use it, and occupies a clear niche that distinguishes it from 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 users would say: 'dependency injection', 'DI', 'Golang', 'Go', 'inversion of control', 'service containers', 'wiring dependencies', 'singletons', 'service factories', 'tightly coupled code', plus specific library names users might reference. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive with a clear niche: dependency injection specifically in Go/Golang, with named libraries and specific architectural patterns. Unlikely to conflict with general Go skills or DI skills for other languages. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
72%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a well-structured, comprehensive DI skill for Go that excels in actionability and progressive disclosure. The code examples are executable and the decision table is genuinely useful for choosing the right approach. The main weaknesses are some verbosity in explaining DI fundamentals that Claude already knows, and the refactoring workflow could benefit from more explicit validation steps.
Suggestions
Trim the 'Why Dependency Injection?' section significantly — Claude understands DI concepts; a 1-2 line reminder is sufficient instead of a full table.
Add explicit validation/verification steps to the 'Refactor mode' workflow (e.g., 'run tests after each migration step', 'verify no remaining global state with a linter check').
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is fairly comprehensive but includes some unnecessary explanatory content that Claude already knows (e.g., the 'Why Dependency Injection?' table explaining basic DI concepts, the opening paragraph defining DI). The 'Bad' code example and the 'Common Mistakes' table add value but the overall document could be tightened by ~20-30%. | 2 / 3 |
Actionability | The skill provides fully executable Go code examples for manual DI, google/wire, uber-go/fx, and samber/do. The testing section includes complete, copy-paste-ready mock and test code. The decision table gives concrete criteria for choosing an approach. | 3 / 3 |
Workflow Clarity | The skill has clear decision tables and comparison matrices, but the 'Refactor mode' workflow with parallel sub-agents lacks explicit validation checkpoints or a step-by-step sequence with verification. The 'When to Adopt a DI Library' table provides guidance but the migration path from manual to library-based DI lacks explicit steps and validation. | 2 / 3 |
Progressive Disclosure | Excellent progressive disclosure with a clear overview in the main file and well-signaled one-level-deep references to detailed examples (./references/manual-di.md, ./references/google-wire.md, ./references/uber-dig-fx.md, ./references/samber-do.md). Cross-references to related skills are clearly listed at the end. | 3 / 3 |
Total | 10 / 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
b88f91d
- 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.