golang-samber-oops
Structured error handling in Golang with samber/oops — error builders, stack traces, error codes, error context, error wrapping, error attributes, user-facing vs developer messages, panic recovery, and logger integration. Apply when using or adopting samber/oops, or when the codebase already imports github.com/samber/oops.
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 clearly identifies the specific library (samber/oops), lists comprehensive concrete capabilities, and provides explicit trigger conditions including both adoption scenarios and existing usage detection via import path. It uses proper third-person voice and is concise yet thorough.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions and concepts: error builders, stack traces, error codes, error context, error wrapping, error attributes, user-facing vs developer messages, panic recovery, and logger integration. | 3 / 3 |
Completeness | Clearly answers both 'what' (structured error handling with samber/oops including specific features) and 'when' ('Apply when using or adopting samber/oops, or when the codebase already imports github.com/samber/oops'). | 3 / 3 |
Trigger Term Quality | Includes highly natural and specific trigger terms users would say: 'samber/oops', 'error handling', 'Golang', 'stack traces', 'error codes', 'error wrapping', 'panic recovery', and the import path 'github.com/samber/oops'. These cover both library-specific and general Go error handling terminology. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive — targets a specific Go library (samber/oops) with a clear niche. The explicit library name and import path make it very unlikely to conflict with general Go error handling skills or other language error handling 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, actionable skill with excellent code examples covering real-world scenarios across multiple architectural layers. Its main weaknesses are moderate verbosity (motivational sections, persona line, Context7 mention) and a lack of explicit validation/verification steps for confirming errors are properly structured. The progressive disclosure is reasonable but could benefit from splitting the comprehensive reference table and some scenarios into separate files.
Suggestions
Remove the 'Why use samber/oops' section and the persona line — Claude doesn't need motivation or role-play framing to apply the patterns.
Add a brief validation step or testing pattern showing how to verify that an oops error carries expected attributes (e.g., a test helper or assertion example), which would improve workflow clarity.
Move the full builder methods table to a reference file (e.g., references/builder-api.md) and keep only the most common 4-5 methods inline to improve progressive disclosure.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The 'Why use samber/oops' section explains motivations Claude doesn't need (standard Go errors lack context), and the opening persona line and some preamble are unnecessary. However, the bulk of the content is reference tables and code examples that earn their place. The disclaimer about Context7 is noise. | 2 / 3 |
Actionability | Every pattern is backed by fully executable Go code examples covering multiple architectural layers (repository, handler, service). The builder method table is comprehensive, and the do/don't examples with clear rationale make guidance immediately actionable. | 3 / 3 |
Workflow Clarity | The skill clearly sequences layered error wrapping (controller → service → repository) and shows context propagation through middleware. However, there are no explicit validation checkpoints — e.g., no guidance on verifying that errors carry expected attributes, no testing/verification steps for confirming structured errors appear correctly in APM tools. | 2 / 3 |
Progressive Disclosure | There is a reference to './references/advanced.md' for advanced patterns and cross-references to related skills, which is good. However, no bundle files were provided to confirm the advanced.md exists, and the main file is quite long (~200+ lines) with some content (like the full builder methods table and all scenarios) that could be split into reference files for better progressive disclosure. | 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.