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.
84
82%
Does it follow best practices?
Impact
Pending
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. 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 use: '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 due to the specific library reference (samber/oops) and the Go language context. Unlikely to conflict with generic error handling skills or other language-specific skills. The import path further narrows the trigger scope. | 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 concrete code examples covering multiple architectural layers and clear do/don't patterns. Its main weaknesses are moderate verbosity in introductory sections (explaining motivations and concepts Claude already knows) and a somewhat monolithic structure that could benefit from offloading the complete builder methods table and some scenarios to reference files. The workflow guidance is good for a library-usage skill but lacks explicit validation checkpoints.
Suggestions
Remove or significantly trim the 'Why use samber/oops' section and the persona line — Claude doesn't need motivation to use a library it's been instructed to use.
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.
Remove filler sentences like 'This skill is not exhaustive. Please refer to library documentation...' and the Context7 mention — these waste tokens without adding actionable guidance.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The 'Why use samber/oops' section explains motivations Claude can infer, and the persona line adds little value. The builder methods table and code examples are efficient, but the introductory paragraphs and some commentary ('This skill is not exhaustive...') are unnecessary padding. | 2 / 3 |
Actionability | The skill provides fully executable Go code examples across multiple layers (repository, handler, service), concrete builder method references with a complete table, clear do/don't patterns with copy-paste ready code, and specific guidance on accessing error information and output formats. | 3 / 3 |
Workflow Clarity | The layered wrapping pattern (Controller → Service → Repository) is clearly sequenced, and the context propagation middleware→handler flow is well-demonstrated. However, there are no explicit validation checkpoints — e.g., no guidance on verifying that oops errors are properly structured before logging/sending to APM, and no feedback loop for checking that attributes are correctly propagated. | 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, the bundle has no files, so we can't verify the advanced.md exists. The main file itself is quite long (~200 lines of content) and the builder methods table plus all scenarios could benefit from being split into a reference file, keeping the SKILL.md 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
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.