golang-samber-do
Dependency injection in Golang using samber/do — service containers, lifecycle management, scopes, health checks, graceful shutdown, and module organization. Apply when using or adopting samber/do, when the codebase imports github.com/samber/do or github.com/samber/do/v2, or when refactoring manual constructor injection into a DI container.
67
82%
Does it follow best practices?
Impact
—
No eval scenarios have been run
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 hits all the marks. It provides specific capabilities, includes natural trigger terms including exact import paths, explicitly states both what the skill does and when to apply it, and is highly distinctive due to its focus on a specific library. The description is concise yet comprehensive.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions and concepts: service containers, lifecycle management, scopes, health checks, graceful shutdown, and module organization. These are all concrete, well-defined capabilities. | 3 / 3 |
Completeness | Clearly answers both 'what' (dependency injection with samber/do covering service containers, lifecycle management, scopes, etc.) and 'when' with explicit triggers ('Apply when using or adopting samber/do, when the codebase imports github.com/samber/do...or when refactoring manual constructor injection into a DI container'). | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural trigger terms: 'dependency injection', 'Golang', 'samber/do', 'DI container', 'service containers', specific import paths like 'github.com/samber/do/v2', and 'constructor injection'. These are terms a developer would naturally use. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive — targets a specific Go library (samber/do) with specific import paths. Very unlikely to conflict with general Go skills or other DI frameworks. The niche is clearly defined. | 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, actionable skill with executable Go code covering the key features of samber/do v2. Its main weaknesses are moderate verbosity (best practice explanations, duplicated examples, unnecessary disclaimers) and the lack of validation/debugging checkpoints in the workflow. The progressive disclosure structure is reasonable but the referenced bundle files are missing.
Suggestions
Remove the persona block and the 'This skill is not exhaustive' disclaimer — these consume tokens without adding actionable value for Claude.
Trim best practice explanations to just the imperative (e.g., 'Depend on interfaces, not concrete types') without the rationale sentences that Claude already understands.
Add a brief troubleshooting/validation section covering common failure modes: circular dependency errors, missing provider errors, and how to use `do.HealthCheck()` or list registered services to verify wiring.
Fix the duplicated `do.ProvideValue` example under 'Register an eager service' — either show the actual eager registration API or remove the duplicate.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Generally efficient but has some unnecessary padding: the persona block, the explanation of why each best practice matters (Claude knows these), the 'This skill is not exhaustive' disclaimer, and the eager service example duplicates the ProvideValue line. The quick reference tables are useful but add length. | 2 / 3 |
Actionability | Provides fully executable, copy-paste-ready Go code for every concept: registration, invocation, dependency chains, implicit aliasing, named services, package organization, and a full application setup. All examples use real types and real function signatures. | 3 / 3 |
Workflow Clarity | The numbered steps (Define → Invoke → Dependencies) provide a clear sequence for basic usage, and the full application setup shows the composition root pattern. However, there are no validation checkpoints or error recovery guidance — e.g., what happens when a provider fails, how to debug circular dependencies, or how to verify the container is correctly wired. | 2 / 3 |
Progressive Disclosure | References to ./references/advanced.md and ./references/testing.md are well-signaled and one level deep, which is good. However, no bundle files were provided, so these references are unverifiable. The inline content is reasonably scoped but the quick reference tables could arguably live in a separate reference file to keep the main skill leaner. | 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
8c7e016
- 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.