golang-testing
Go testing patterns including table-driven tests, subtests, benchmarks, fuzzing, and test coverage. Follows TDD methodology with idiomatic Go practices.
65
53%
Does it follow best practices?
Impact
80%
1.12xAverage score across 3 eval scenarios
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./docs/zh-TW/skills/golang-testing/SKILL.mdQuality
Discovery
50%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 occupies a clear niche, but critically lacks any explicit trigger guidance ('Use when...') telling Claude when to select this skill. The trigger terms are decent but could be expanded with more common user phrasings like 'unit test', 'go test', or '_test.go'.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when the user asks about writing Go tests, running benchmarks, improving test coverage, or following TDD in Go.'
Include additional natural trigger terms users might say, such as 'unit test', 'go test', '_test.go', 'testing package', 'mock', or 'test helper'.
| 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, well-defined testing concepts. | 3 / 3 |
Completeness | Describes what the skill covers (Go testing patterns) but has no explicit 'Use when...' clause or equivalent trigger guidance. Per the rubric, a missing 'Use when...' clause should cap completeness at 2, and since the 'when' is entirely absent (not even implied beyond the domain), this scores at 1. | 1 / 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 | The combination of Go language + testing patterns creates a clear, distinct niche. Terms like 'table-driven tests', 'fuzzing', and 'Go' are highly specific and unlikely to conflict with other skills. | 3 / 3 |
Total | 9 / 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 comprehensive, actionable Go testing patterns with excellent executable code examples covering table-driven tests, subtests, benchmarks, fuzzing, mocking, and HTTP handler testing. However, it suffers from being a monolithic document (~400+ lines) that could be significantly improved by splitting into focused reference files with a concise overview. Some sections explain concepts Claude already knows (basic TDD steps, what table-driven tests are) adding unnecessary verbosity.
Suggestions
Split the monolithic content into separate reference files (e.g., BENCHMARKS.md, MOCKING.md, FUZZING.md, HTTP_TESTING.md) and keep SKILL.md as a concise overview with links to each.
Remove or drastically shorten the TDD step-by-step walkthrough — Claude already understands red-green-refactor; a 2-line summary with the cycle diagram suffices.
Add validation/feedback loop guidance: what to do when coverage drops, how to diagnose flaky tests, how to handle fuzz test failures with corpus management.
Trim explanatory comments in code examples (e.g., '// 佔位符', '// 斷言...') and descriptive headers that restate what the code already shows.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is quite long (~400+ lines) and includes many patterns that an experienced Go developer (or Claude) would already know. The TDD step-by-step walkthrough with comments like '步驟 1', '步驟 2' explaining basic red-green-refactor is verbose. However, the code examples themselves are lean and well-structured, and the table-driven test patterns serve as useful reference templates. | 2 / 3 |
Actionability | Every section provides fully executable, copy-paste ready Go code examples with concrete inputs and expected outputs. Commands for running tests, benchmarks, fuzzing, and coverage are all specific and complete. The CI/CD YAML snippet is also directly usable. | 3 / 3 |
Workflow Clarity | The TDD workflow (RED-GREEN-REFACTOR) is clearly sequenced with explicit steps and verification commands. However, there are no validation checkpoints or feedback loops for the broader testing workflow — e.g., no guidance on what to do when coverage drops below threshold, no error recovery steps for failing fuzz tests, and the CI/CD section lacks failure handling guidance. | 2 / 3 |
Progressive Disclosure | This is a monolithic wall of content with no references to external files. All patterns — table-driven tests, subtests, benchmarks, fuzzing, HTTP testing, mocking, golden files, CI/CD — are inlined in a single massive document. This would benefit greatly from splitting into separate reference files (e.g., BENCHMARKS.md, MOCKING.md, FUZZING.md) with a concise overview in the main SKILL.md. | 1 / 3 |
Total | 8 / 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 (711 lines); consider splitting into references/ and linking | Warning |
Total | 10 / 11 Passed | |
- Repository
- ysyecust/everything-claude-code
- Commit
79cc4e3
- 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.