golang-design-patterns
Idiomatic Golang design patterns — functional options, constructors, error flow and cascading, resource management and lifecycle, graceful shutdown, resilience, architecture, dependency injection, data handling, streaming, and more. Apply when explicitly choosing between architectural patterns, implementing functional options, designing constructor APIs, setting up graceful shutdown, applying resilience patterns, or asking which idiomatic Go pattern fits a specific problem.
69
86%
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 a strong skill description that clearly identifies its domain (idiomatic Go design patterns), lists numerous specific capabilities, and includes an explicit 'Apply when...' clause with natural trigger scenarios. It uses proper third-person voice and covers both what the skill does and when it should be selected. The description is comprehensive without being padded with fluff.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete patterns: functional options, constructors, error flow and cascading, resource management and lifecycle, graceful shutdown, resilience, architecture, dependency injection, data handling, streaming. These are all concrete, recognizable Go design patterns. | 3 / 3 |
Completeness | Clearly answers both 'what' (idiomatic Golang design patterns covering functional options, constructors, error flow, etc.) and 'when' (explicit 'Apply when...' clause listing specific trigger scenarios like choosing between architectural patterns, implementing functional options, designing constructor APIs). | 3 / 3 |
Trigger Term Quality | Includes natural keywords a Go developer would use: 'functional options', 'constructors', 'graceful shutdown', 'resilience patterns', 'dependency injection', 'idiomatic Go', 'architectural patterns'. These are terms developers naturally use when seeking Go design guidance. | 3 / 3 |
Distinctiveness Conflict Risk | Clearly scoped to Go-specific idiomatic design patterns, which is a distinct niche. The combination of 'Golang' with specific pattern names like 'functional options' and 'graceful shutdown' makes it unlikely to conflict with general coding skills or other language-specific skills. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
72%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a well-structured Go design patterns skill that provides concrete, executable code examples and excellent progressive disclosure through cross-references to companion skills and reference files. The main weaknesses are some verbosity in the best practices summary (which partially restates what the sections below cover) and the lack of explicit decision workflows or validation checkpoints for multi-step architectural decisions. Overall it serves well as a pattern catalog with good navigation.
Suggestions
Trim the 21-item best practices summary to remove items that are fully elaborated in sections below or that Claude already knows (e.g., 'use crypto/rand for keys' and 'use strings.Builder'), keeping it as a quick-reference index rather than a teaching list.
Add a brief decision workflow for the architecture section — e.g., a decision tree or checklist for when to use clean vs hexagonal vs flat layout based on project size/complexity.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Generally efficient with good use of tables and concise code examples, but the best practices summary (21 items) is lengthy and some items repeat what's elaborated below. Some explanations like 'they scale better as APIs evolve' and the init() bullet points explain things Claude already knows about Go. | 2 / 3 |
Actionability | Provides fully executable, copy-paste-ready Go code for functional options, defer patterns, timeout patterns, embed directives, enum declarations, and regex compilation. The code examples are complete and idiomatic. | 3 / 3 |
Workflow Clarity | The skill covers many patterns but presents them as independent recipes rather than sequenced workflows. The design/review modes are mentioned but lack explicit step-by-step processes with validation checkpoints. For a pattern catalog this is acceptable, but the architecture section ('ask the developer which architecture they prefer') lacks a clear decision workflow. | 2 / 3 |
Progressive Disclosure | Excellent structure with a clear overview in SKILL.md and well-signaled one-level-deep references to both bundle files (references/data-handling.md, references/architecture.md, etc.) and cross-referenced skills. The detailed guides table and cross-references section provide easy navigation. However, bundle files were not provided, so we cannot verify the referenced paths exist. | 3 / 3 |
Total | 10 / 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.