golang-error-handling
Idiomatic Golang error handling — creation, wrapping with %w, errors.Is/As, errors.Join, custom error types, sentinel errors, panic/recover, the single handling rule, structured logging with slog, HTTP request logging middleware, and samber/oops for production errors. Built to make logs usable at scale with log aggregation 3rd-party tools. Apply when creating, wrapping, inspecting, or logging errors in Go code.
75
71%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/golang-error-handling/SKILL.mdQuality
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 defines a specific niche (Go error handling), lists comprehensive concrete capabilities, includes abundant natural trigger terms, and provides an explicit 'Apply when...' clause. It would be easily distinguishable from other skills and highly matchable when users ask about Go error handling topics.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists numerous specific concrete actions and concepts: error creation, wrapping with %w, errors.Is/As, errors.Join, custom error types, sentinel errors, panic/recover, structured logging with slog, HTTP request logging middleware, and samber/oops. This is highly specific and comprehensive. | 3 / 3 |
Completeness | Clearly answers 'what' (idiomatic Go error handling with specific techniques listed) and 'when' with an explicit trigger clause: 'Apply when creating, wrapping, inspecting, or logging errors in Go code.' | 3 / 3 |
Trigger Term Quality | Includes many natural keywords a Go developer would use: 'error handling', 'wrapping', '%w', 'errors.Is', 'errors.As', 'errors.Join', 'sentinel errors', 'panic/recover', 'slog', 'Go code', 'logging errors'. These cover a wide range of terms users would naturally mention. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive — narrowly scoped to Go error handling specifically, with Go-specific terminology (errors.Is/As, %w, slog, samber/oops) that would not conflict with general coding skills or error handling in other languages. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
42%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The skill excels at progressive disclosure and organization — it's a well-structured overview that clearly points to detailed references. However, it critically lacks any executable code examples in the main body, making it more of a table of contents than an actionable skill. The best practices list is useful but reads as declarative rules rather than concrete guidance Claude can immediately apply.
Suggestions
Add at least 2-3 minimal executable Go code examples in the main body (e.g., error wrapping with fmt.Errorf, errors.Is/As usage, slog structured logging) so the skill is actionable without requiring reference file lookups.
For the coding and review modes, add concrete step-by-step workflows with validation checkpoints (e.g., 'After wrapping errors, verify no log-and-return pairs exist by grepping for patterns like `log.*\n.*return.*err`').
Trim the persona and modes section — Claude doesn't need to be told it's a 'Go reliability engineer'; focus those tokens on concrete examples instead.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The best practices summary is reasonably efficient, but the persona/modes section adds overhead that doesn't directly help Claude handle errors. Some rules explain things Claude already knows (e.g., 'errors MUST be checked'). The sub-agent parallelization section is useful but somewhat verbose. | 2 / 3 |
Actionability | The skill body contains zero executable code examples — no Go snippets for wrapping, sentinel errors, custom types, slog usage, or samber/oops. It describes what to do but never shows how with concrete, copy-paste-ready code. All concrete guidance is deferred to reference files. | 1 / 3 |
Workflow Clarity | The three modes (coding, review, audit) provide some workflow structure, and the audit parallelization section gives clear sub-agent assignments. However, there are no validation checkpoints, no feedback loops for catching violations, and the coding/review modes lack step-by-step sequences. | 2 / 3 |
Progressive Disclosure | Excellent structure: a concise summary of 15 rules at the top, clearly signaled one-level-deep references to three detailed reference files, cross-references to related skills, and external library links. Navigation is easy and well-organized. | 3 / 3 |
Total | 8 / 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.