jbvc/golang-testing
Go testing patterns including table-driven tests, subtests, benchmarks, fuzzing, and test coverage. Follows TDD methodology with idiomatic Go practices.
67
67%
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 as a Go-specific testing skill. Its main weaknesses are the lack of an explicit 'Use when...' clause and missing some common natural trigger terms users might use when asking for help with Go tests.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when the user asks to write, run, or improve Go tests, or mentions _test.go files, go test, or test coverage.'
Include additional natural trigger terms like 'unit test', 'go test', '_test.go', 'mock', 'test helper', and 'testing package' to improve keyword coverage.
| 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 does this do' (Go testing patterns with specific techniques), 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 natural user phrases like 'unit test', 'go test', '_test.go', 'testing package', or 'write tests for'. | 2 / 3 |
Distinctiveness Conflict Risk | Clearly scoped to Go testing specifically, with distinct Go-idiomatic terms like 'table-driven tests' and 'fuzzing'. 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 that are highly actionable, but it is far too verbose and monolithic. It explains standard Go testing patterns that Claude already knows in exhaustive detail, consuming excessive tokens. The content would benefit greatly from being restructured as a brief overview with references to separate detailed files.
Suggestions
Reduce the SKILL.md to a concise overview (~50-80 lines) covering the key patterns with minimal examples, and move detailed code examples for each topic (benchmarks, fuzzing, HTTP testing, mocking, golden files) into separate referenced files.
Remove explanations of concepts Claude already knows—table-driven tests, subtests, t.Helper(), httptest patterns are standard Go knowledge. Focus only on project-specific conventions or non-obvious patterns.
Cut the 'When to Activate' section and the 'Best Practices' DO/DON'T list, which are generic TDD advice rather than actionable skill content.
Add a brief quick-reference section at the top with just the most common commands and a one-liner for each pattern, then link to detailed files for each topic.
| 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 padding. Much of this is standard Go knowledge that doesn't need to be spelled out in full code examples. | 1 / 3 |
Actionability | Every section contains fully executable, copy-paste ready Go code examples with proper imports, complete function signatures, and runnable commands. The code is idiomatic Go and includes both the test code and the commands to run them. | 3 / 3 |
Workflow Clarity | The TDD RED-GREEN-REFACTOR cycle is clearly sequenced with steps, but the overall document reads more as a reference catalog of patterns than a workflow. There are no validation checkpoints or feedback loops for when tests fail unexpectedly or coverage drops below thresholds—the CI/CD section mentions a coverage check but doesn't describe what to do on failure. | 2 / 3 |
Progressive Disclosure | This is a monolithic wall of text with no references to external files. All content—basic tests, table-driven tests, benchmarks, fuzzing, HTTP testing, mocking, CI/CD—is inlined in a single massive document. Much of this should be split into separate reference files (e.g., BENCHMARKS.md, FUZZING.md, HTTP_TESTING.md) with the SKILL.md serving as a concise overview. | 1 / 3 |
Total | 7 / 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 (720 lines); consider splitting into references/ and linking | Warning |
Total | 10 / 11 Passed | |
Reviewed
Table of Contents