tdg-personal/golang-patterns
Idiomatic Go patterns, best practices, and conventions for building robust, efficient, and maintainable Go applications.
51
51%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Quality
Discovery
22%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 sufficient keyword coverage. The vague framing ('idiomatic patterns, best practices, conventions') provides little guidance for Claude to determine when to select this skill over other Go-related or general coding skills.
Suggestions
Add a 'Use when...' clause with explicit triggers, e.g., 'Use when the user asks for Go code review, idiomatic Go refactoring, or help following Go conventions.'
List specific concrete actions the skill performs, e.g., 'Reviews Go code for idiomatic style, suggests proper error handling patterns, recommends struct design, and enforces naming conventions.'
Include natural trigger terms users would say, such as 'golang', '.go files', 'error handling', 'goroutines', 'interfaces', 'Go modules', 'go fmt', 'go vet'.
| 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 weakly addresses 'what' (Go patterns and best practices) but completely lacks any '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' is itself too vague to earn a 2. | 1 / 3 |
Trigger Term Quality | It includes 'Go' and 'Go applications' which are relevant keywords users might use, but misses common variations like 'golang', '.go files', 'goroutines', 'error handling', 'interfaces', or other specific Go concepts users would naturally mention. | 2 / 3 |
Distinctiveness Conflict Risk | While it specifies Go as the language, the broad terms 'best practices', 'patterns', and 'conventions' could easily overlap with general code review skills, Go-specific linting skills, or any Go development skill. It's somewhat specific due to the Go focus but not clearly carved into a distinct niche. | 2 / 3 |
Total | 6 / 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 significantly from being a monolithic document that covers too many topics inline—most of which are standard Go knowledge Claude already possesses. The content would benefit greatly from being restructured as a brief overview with references to topic-specific files.
Suggestions
Split the content into separate files (e.g., ERROR_HANDLING.md, CONCURRENCY.md, INTERFACES.md, PERFORMANCE.md) and make SKILL.md a concise overview with links to each.
Remove patterns Claude already knows well (basic error handling, interface composition, slice preallocation) and focus on project-specific conventions or non-obvious patterns that differ from standard Go practices.
Add a brief workflow section that sequences how to apply these patterns during code writing or review (e.g., 'check error handling → verify concurrency safety → run linters').
Trim explanatory prose like 'Go favors simplicity over cleverness' and 'Errors are values' descriptions—these are well-known Go proverbs that don't need restating.
| 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 scenarios without clear sequencing, and there's no guidance on how to apply these patterns in order (e.g., when refactoring). 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, much of this content should be split into separate reference files with the SKILL.md serving as a concise overview with links. | 1 / 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 |
|---|---|---|
skill_md_line_count | SKILL.md is long (675 lines); consider splitting into references/ and linking | Warning |
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 9 / 11 Passed | |
Reviewed
Table of Contents