Go testing patterns including table-driven tests, subtests, benchmarks, fuzzing, and test coverage. Follows TDD methodology with idiomatic Go practices.
77
72%
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 effectively communicates specific Go testing capabilities with good technical detail and clear language-specific focus. However, it lacks explicit trigger guidance ('Use when...') which is critical for skill selection, and could benefit from more natural user-facing keywords beyond technical terminology.
Suggestions
Add a 'Use when...' clause with trigger terms like 'write Go tests', 'test my Go code', 'add unit tests', or 'improve test coverage'
Include common file pattern triggers like '_test.go' and natural phrases users might say like 'write tests for this function' or 'help me test'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: 'table-driven tests, subtests, benchmarks, fuzzing, and test coverage' along with methodology 'TDD' and 'idiomatic Go practices'. | 3 / 3 |
Completeness | Clearly answers 'what' with specific testing patterns and practices, but lacks an explicit 'Use when...' clause or trigger guidance for when Claude should select this skill. | 2 / 3 |
Trigger Term Quality | Includes relevant technical terms like 'Go testing', 'table-driven tests', 'benchmarks', 'fuzzing', 'TDD', but missing common user variations like 'unit tests', 'test file', '_test.go', or 'write tests'. | 2 / 3 |
Distinctiveness Conflict Risk | Clearly scoped to Go language testing with specific Go-idiomatic patterns (table-driven tests, subtests); unlikely to conflict with general testing skills or other language testing skills. | 3 / 3 |
Total | 10 / 12 Passed |
Implementation
77%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a solid, comprehensive Go testing skill with excellent actionability and clear workflows. The code examples are production-ready and cover the full spectrum of Go testing patterns. The main weakness is its length - at 500+ lines, it could benefit from splitting into a concise overview with references to detailed topic files, and some introductory explanations could be trimmed.
Suggestions
Split advanced topics (fuzzing, benchmarks, HTTP testing, mocking) into separate reference files and link from a concise overview section
Remove the TDD conceptual explanation - Claude knows RED-GREEN-REFACTOR; keep only the Go-specific code example
Trim the '何時啟用' section which describes when to use testing patterns that Claude can infer from context
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is comprehensive but includes some sections that could be tightened. The TDD workflow explanation and some introductory text add tokens without providing unique value Claude wouldn't already know. However, most code examples are lean and purposeful. | 2 / 3 |
Actionability | Excellent actionability with fully executable, copy-paste ready code examples throughout. Every pattern includes complete, working Go code with proper imports, test commands, and expected outputs. The bash commands section provides specific, runnable commands. | 3 / 3 |
Workflow Clarity | Clear TDD workflow with explicit RED-GREEN-REFACTOR cycle and step-by-step progression. Test commands are well-organized with clear purposes. The CI/CD integration example shows validation checkpoints with coverage thresholds. | 3 / 3 |
Progressive Disclosure | Content is well-organized with clear section headers, but it's a monolithic document that could benefit from splitting advanced topics (fuzzing, benchmarks, HTTP testing) into separate reference files. No external file references are provided for deeper dives. | 2 / 3 |
Total | 10 / 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 | |
ae2cadd
Table of Contents
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.