jbvc/golang-patterns
Idiomatic Go patterns, best practices, and conventions for building robust, efficient, and maintainable Go applications.
52
52%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Quality
Discovery
14%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 description reads more like a tagline than a functional skill description. It lacks concrete actions, explicit trigger conditions, and distinctive language that would help Claude select it appropriately from a pool of skills. The vague buzzwords ('idiomatic', 'robust', 'efficient', 'maintainable') add no discriminative value.
Suggestions
List specific concrete actions the skill performs, e.g., 'Reviews Go code for idiomatic patterns, suggests error handling improvements, refactors to use interfaces and composition, applies standard project layout conventions.'
Add an explicit 'Use when...' clause with natural trigger terms, e.g., 'Use when the user asks for Go/golang code review, wants help with Go error handling, channel patterns, struct design, or asks to make Go code more idiomatic.'
Include common user-facing keywords like 'golang', 'Go code', 'error handling', 'goroutines', 'concurrency', '.go files' to improve trigger term coverage and distinctiveness.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description uses vague, abstract language like 'idiomatic patterns', 'best practices', and 'conventions' without listing any concrete actions. It doesn't specify what the skill actually does (e.g., 'reviews code for idiomatic style', 'refactors functions to use Go conventions', 'generates Go structs with proper tags'). | 1 / 3 |
Completeness | The description vaguely addresses 'what' (Go patterns and best practices) but provides no 'when' clause or explicit trigger guidance. There is no 'Use when...' or equivalent, which per the rubric should cap completeness at 2, and the 'what' itself is too vague to even earn a 2. | 1 / 3 |
Trigger Term Quality | It includes 'Go' as a relevant keyword, and terms like 'Go applications' and 'best practices' are somewhat natural. However, it misses common user trigger terms like 'golang', 'Go code review', 'error handling', 'goroutines', 'interfaces', or specific Go concepts users would mention. | 2 / 3 |
Distinctiveness Conflict Risk | This description is extremely generic and could overlap with any Go-related skill, code review skill, or general programming best practices skill. There is nothing that carves out a distinct niche or differentiates it from other Go or coding skills. | 1 / 3 |
Total | 5 / 12 Passed |
Implementation
57%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The skill provides high-quality, actionable Go code examples with clear good/bad comparisons, which is its strongest aspect. However, it suffers from being a comprehensive Go reference guide rather than a focused skill — much of the content covers patterns Claude already knows well, and the monolithic structure (~400 lines) wastes context window space. It would be significantly improved by trimming to project-specific conventions and splitting detailed patterns into referenced sub-files.
Suggestions
Split the content into a concise SKILL.md overview (~50-80 lines) with references to separate files like CONCURRENCY.md, ERROR_HANDLING.md, INTERFACES.md for detailed patterns.
Remove patterns that are standard Go knowledge (e.g., basic error wrapping, small interfaces, slice preallocation) and focus on project-specific conventions or non-obvious decisions.
Add a brief workflow section that sequences how to apply these patterns during code writing vs. code review, with validation steps (e.g., 'run golangci-lint before committing').
Remove the Quick Reference table and explanatory prose like 'Go favors simplicity over cleverness' — Claude already knows these Go proverbs.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is quite long (~400 lines) and covers many patterns Claude already knows well as an LLM trained on Go documentation. While the examples are good, much of this is standard Go knowledge (error handling, interfaces, package naming) that doesn't need to be spelled out. The quick reference table and some explanatory text like 'Go favors simplicity over cleverness' are unnecessary padding. | 2 / 3 |
Actionability | Nearly all guidance is backed by concrete, executable Go code examples with clear good/bad comparisons. The tooling section provides copy-paste ready commands, and the linter configuration is a complete, usable YAML file. Code examples are realistic and complete. | 3 / 3 |
Workflow Clarity | This is primarily a patterns/conventions skill rather than a multi-step workflow skill, so explicit validation checkpoints are less critical. However, the 'When to Activate' section lists triggers without clear sequencing, and there's no guidance on how to apply these patterns in order (e.g., when reviewing code, what to check first). The tooling section lists commands but doesn't sequence them into a development workflow. | 2 / 3 |
Progressive Disclosure | This is a monolithic wall of content with no references to external files. At ~400 lines covering error handling, concurrency, interfaces, package organization, struct design, performance, tooling, and anti-patterns, this would benefit greatly from splitting into separate reference files with a concise overview in the main SKILL.md. | 1 / 3 |
Total | 8 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
skill_md_line_count | SKILL.md is long (674 lines); consider splitting into references/ and linking | Warning |
Total | 10 / 11 Passed | |
Reviewed
Table of Contents