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-testing-specific skill. However, it lacks an explicit 'Use when...' clause which limits its completeness score, and could benefit from additional natural trigger terms that users would commonly use when asking for 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 _test.go files, go test, or test coverage.'
Include additional natural trigger terms like 'unit tests', 'write tests', 'go test', '_test.go', 'testing package', 'mock', or 'test helpers' 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 'write tests', 'unit tests', '_test.go', 'go test', or 'testing package'. | 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 skill provides highly actionable, executable Go testing patterns covering a comprehensive range of topics. Its main weakness is that it's a monolithic document that could be significantly improved by splitting into focused reference files with a concise overview. The content is somewhat verbose for Claude's capabilities, explaining patterns that are well-known in the Go ecosystem, though the code examples themselves are clean and practical.
Suggestions
Split the content into separate files (e.g., TABLE_TESTS.md, BENCHMARKS.md, FUZZING.md, MOCKING.md, HTTP_TESTING.md) and keep SKILL.md as a concise overview with links to each topic.
Trim the TDD walkthrough section—Claude already understands TDD; a brief reminder with just the RED-GREEN-REFACTOR cycle and one compact example would suffice.
Add a workflow section with explicit validation checkpoints, e.g., 'After writing tests: 1. Run `go test -race ./...` 2. Check coverage meets threshold 3. If coverage < target, identify untested paths with `go tool cover -html` 4. Add missing test cases and re-run.'
Remove or condense the 'Best Practices' do/don't list—most items are general Go testing knowledge that Claude already possesses.
| 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: 定義介面/簽章' is verbose. However, the code examples themselves are lean and well-structured, and the content serves as a comprehensive reference. Some sections like the basic Add example and the CI/CD YAML could be trimmed. | 2 / 3 |
Actionability | Every section provides fully executable, copy-paste ready Go code with concrete examples. Commands are specific (e.g., `go test -bench=BenchmarkProcess -benchmem`), test patterns include complete function signatures, and even the CI/CD section has a working GitHub Actions YAML. The code is real Go, not pseudocode. | 3 / 3 |
Workflow Clarity | The TDD RED-GREEN-REFACTOR cycle 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., what to do when coverage drops, how to handle flaky test detection results, or iterative debugging). The test commands section is a flat list without guidance on when to use which command. | 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 file. Given the breadth of topics (~400+ lines), this content would benefit significantly from being split into separate reference files with a concise overview in 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.