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.
87
86%
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 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 provides enough specificity to distinguish it from general Go programming or other language pattern skills.
| 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 with strong actionability through executable code examples and excellent progressive disclosure via clear references to detailed guides and related skills. The main weaknesses are moderate verbosity in the best practices summary (some items could be consolidated) and the lack of explicit multi-step workflows with validation checkpoints for the more complex patterns like graceful shutdown or architecture selection.
Suggestions
Trim the 21-item best practices summary to ~12 items by removing entries that are fully covered in referenced skills (e.g., items 12, 17 which just point to other skills) and consolidating related items.
Add a concrete decision workflow for the Architecture section (e.g., 'If <5 packages → flat layout; if domain logic is complex → clean/hex; ask developer if unclear') with explicit checkpoints.
| 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 why to avoid init() include details Claude already knows (e.g., 'runs before main() and tests'). The cross-references section at the end is somewhat redundant with inline references throughout. | 2 / 3 |
Actionability | Provides fully executable, copy-paste ready Go code for functional options, resource management, timeouts, regex compilation, and embed directives. The code examples are complete and idiomatic, with concrete usage patterns shown alongside definitions. | 3 / 3 |
Workflow Clarity | The skill covers many patterns but doesn't provide clear multi-step workflows with validation checkpoints. The design/review modes are mentioned but lack explicit step sequences. Architecture section says 'ask the developer' but doesn't define a decision workflow. For a pattern catalog this is acceptable, but the resilience section (retry with context checks) lacks a complete feedback loop example. | 2 / 3 |
Progressive Disclosure | Excellent structure with a clear overview, inline code for core patterns, and well-signaled one-level-deep references to both bundle files (references/data-handling.md, references/resource-management.md, references/architecture.md, etc.) and cross-skill references. The detailed guides table provides clear navigation. However, bundle files were not provided, so we can't 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
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.