tdg-personal/golang-testing
Go testing patterns including table-driven tests, subtests, benchmarks, fuzzing, and test coverage. Follows TDD methodology with idiomatic Go practices.
65
65%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Quality
Discovery
67%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
The description does well at listing specific Go testing capabilities and is clearly distinguishable from other skills. However, it lacks an explicit 'Use when...' clause, which limits Claude's ability to know exactly when to select this skill. Adding natural trigger terms users might say (e.g., 'unit test', 'go test') would also improve selection accuracy.
Suggestions
Add a 'Use when...' clause, e.g., 'Use when the user asks about writing Go tests, test coverage, benchmarking Go code, or mentions _test.go files.'
Include additional natural trigger terms users might say, such as 'unit test', 'go test', 'testing package', 'mock', 'test helpers', or '_test.go'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions/patterns: table-driven tests, subtests, benchmarks, fuzzing, test coverage, and TDD methodology. These are all concrete, identifiable testing techniques. | 3 / 3 |
Completeness | Clearly answers 'what' (Go testing patterns with specific techniques listed), but lacks an explicit 'Use when...' clause or equivalent trigger guidance. The 'when' is only implied by the domain description. | 2 / 3 |
Trigger Term Quality | Includes good Go-specific testing terms like 'table-driven tests', 'subtests', 'benchmarks', 'fuzzing', 'test coverage', and 'TDD'. However, it misses common user phrases like 'unit test', 'go test', '_test.go', 'testing package', or 'mock'. | 2 / 3 |
Distinctiveness Conflict Risk | Clearly scoped to Go testing specifically, with distinct Go-idiomatic terms like 'table-driven tests' and 'fuzzing' that are unlikely to conflict with general testing skills or other language-specific testing skills. | 3 / 3 |
Total | 10 / 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 provides comprehensive, executable Go testing examples but suffers significantly from verbosity and lack of progressive disclosure. It reads as an exhaustive Go testing tutorial rather than a concise skill that adds value beyond Claude's existing knowledge. The content would be far more effective as a brief overview with references to separate detailed files for each testing pattern.
Suggestions
Reduce the main SKILL.md to a concise overview (~50-80 lines) covering the key patterns with minimal examples, and move detailed examples (HTTP testing, mocking, fuzzing, benchmarks) into separate referenced files like BENCHMARKS.md, FUZZING.md, MOCKING.md
Remove explanations of concepts Claude already knows well—table-driven tests, subtests, t.Helper(), basic benchmark structure, and the DO/DON'T best practices list are all standard Go knowledge
Add a quick-reference section at the top with just the most commonly needed commands and the table-driven test skeleton, since those are the highest-value items
Focus the skill content on project-specific conventions or non-obvious patterns rather than reproducing Go testing documentation
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | This is extremely verbose at ~500+ lines. It explains basic Go testing concepts Claude already knows (what table-driven tests are, how subtests work, basic benchmark patterns). The 'When to Activate' section, best practices DO/DON'T lists, and coverage target tables are all common knowledge for Claude. Much of this reads like a Go testing tutorial rather than a skill adding novel information. | 1 / 3 |
Actionability | All code examples are fully executable, copy-paste ready Go code with proper imports, function signatures, and test assertions. Commands include exact flags and expected output formats. The examples cover real patterns like HTTP handler testing, mocking with interfaces, and golden file testing. | 3 / 3 |
Workflow Clarity | The TDD RED-GREEN-REFACTOR cycle is clearly sequenced with steps, but there are no validation checkpoints for the broader testing workflow. The skill doesn't address what to do when tests fail unexpectedly, how to debug flaky tests, or provide feedback loops for iterative test development beyond the basic TDD cycle description. | 2 / 3 |
Progressive Disclosure | This is a monolithic wall of text with no references to external files. All content—basic patterns, advanced patterns (fuzzing, benchmarks, mocking, HTTP testing, CI/CD), and reference commands—is inlined into a single massive document. This would benefit enormously from splitting into separate files for benchmarks, fuzzing, mocking patterns, etc. | 1 / 3 |
Total | 7 / 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 (721 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