golang-testing
Go testing patterns including table-driven tests, subtests, benchmarks, fuzzing, and test coverage. Follows TDD methodology with idiomatic Go practices.
71
62%
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
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. However, it lacks an explicit 'Use when...' clause which limits its effectiveness as a skill selector, and it could benefit from more natural trigger terms that users would actually say when requesting help with Go tests.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when the user asks to write, fix, or improve Go tests, or mentions go test, _test.go files, or test coverage.'
Include more natural user-facing trigger terms like 'write tests', 'unit tests', 'go test', '_test.go', 'mock', 'test helpers', and 'testing package'.
| 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' with specific testing patterns and methodology, 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 'write tests', 'unit tests', '_test.go', 'testing package', or 'go test'. | 2 / 3 |
Distinctiveness Conflict Risk | Clearly scoped to Go testing specifically, with distinct Go-specific terminology (table-driven tests, idiomatic Go). Unlikely to conflict with general testing skills or other language-specific testing skills. | 3 / 3 |
Total | 10 / 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.
This is a comprehensive Go testing reference with excellent, executable code examples covering all major testing patterns. Its main weaknesses are its monolithic structure (everything in one large file with no progressive disclosure) and moderate verbosity — some sections explain concepts Claude already knows (TDD basics, what table-driven tests are). Splitting into a concise overview with linked reference files would significantly improve token efficiency and navigability.
Suggestions
Split the content into a concise SKILL.md overview (quick reference of patterns + commands) with links to separate files like TABLE_TESTS.md, BENCHMARKS.md, FUZZING.md, MOCKING.md for detailed examples.
Remove the 'When to activate' section and the TDD conceptual explanation — Claude knows TDD; just show the Go-specific implementation pattern.
Trim explanatory prose like '使用儲存在 testdata/ 中的預期輸出檔案進行測試' and 'Go 測試的標準模式。以最少程式碼達到完整覆蓋' — the code examples are self-explanatory.
Add a brief troubleshooting/validation section for common test failures (e.g., flaky test diagnosis with -count, race condition debugging workflow) to improve workflow clarity.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is quite long (~400+ lines) and covers many patterns comprehensively, but includes some unnecessary commentary (e.g., 'Go 測試的標準模式。以最少程式碼達到完整覆蓋。', the 'When to activate' section, and the final 'Remember' note). The TDD step-by-step walkthrough explains concepts Claude already knows. However, most code examples earn their place. | 2 / 3 |
Actionability | Nearly all guidance is concrete and executable with complete, copy-paste-ready code examples. Commands are specific (e.g., 'go test -bench=BenchmarkProcess -benchmem'), code blocks are fully functional, and patterns cover both happy paths and error cases. | 3 / 3 |
Workflow Clarity | The TDD RED-GREEN-REFACTOR cycle is clearly sequenced with explicit verification steps (run test, verify failure, implement, verify pass). However, the overall document is more of a pattern catalog than a workflow — there are no validation checkpoints for the testing process itself (e.g., no guidance on what to do when coverage drops or tests become flaky beyond 'fix or remove them'). | 2 / 3 |
Progressive Disclosure | The entire skill is a monolithic document with no references to external files. All patterns — table-driven tests, benchmarks, fuzzing, HTTP testing, mocking, golden files, CI/CD — are inlined in a single file. This would benefit greatly from splitting into separate reference files 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
- haniakrim21/everything-claude-code
- Commit
ae2cadd
- 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.