golang-testing
Go testing patterns including table-driven tests, subtests, benchmarks, fuzzing, and test coverage. Follows TDD methodology with idiomatic Go practices.
Install with Tessl CLI
npx tessl i github:ysyecust/everything-claude-code --skill golang-testing70
Does it follow best practices?
If you maintain this skill, you can automatically optimize it using the tessl CLI to improve its score:
npx tessl skill review --optimize ./path/to/skillValidation for skill structure
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 effectively lists specific Go testing capabilities and methodologies, making it clear what the skill covers. However, it critically lacks explicit trigger guidance ('Use when...') which would help Claude know when to select this skill. The trigger terms are somewhat technical and could benefit from more natural user language variations.
Suggestions
Add a 'Use when...' clause with explicit triggers like 'Use when writing Go tests, creating test files, or when the user mentions testing Go code, _test.go files, or test coverage.'
Include more natural user terms like 'unit tests', 'write tests', 'test my Go code', or file patterns like '_test.go' that users would actually say.
| 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 | Describes what the skill does but completely lacks a 'Use when...' clause or any explicit trigger guidance for when Claude should select this skill. | 1 / 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; unlikely to conflict with general testing skills or other language testing skills. | 3 / 3 |
Total | 9 / 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 high-quality, actionable Go testing skill with excellent executable examples and clear workflow guidance. The main weakness is its length - it tries to cover everything in one file rather than using progressive disclosure to separate quick-start content from advanced reference material. Some introductory explanations (TDD concepts, what benchmarks are) could be trimmed since Claude already knows these.
Suggestions
Split advanced topics (fuzzing, HTTP testing, mocking patterns) into separate reference files and link from a concise overview section
Remove or significantly condense the TDD workflow explanation - Claude understands RED-GREEN-REFACTOR; just show the Go-specific implementation
Trim explanatory comments in code examples that state the obvious (e.g., '// 測試結束時清理' before t.Cleanup)
| 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, runnable Go code with proper imports, test commands, and expected outputs clearly shown. | 3 / 3 |
Workflow Clarity | The TDD workflow is explicitly sequenced with RED-GREEN-REFACTOR steps, validation commands shown at each stage, and clear progression. Test commands section provides explicit verification steps. The CI/CD example includes coverage threshold validation. | 3 / 3 |
Progressive Disclosure | Content is well-organized with clear section headers, but it's a monolithic document with no references to external files for advanced topics. The 400+ line document could benefit from splitting detailed patterns (mocking, fuzzing, HTTP testing) into separate reference files. | 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 | |
- 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.