golang-testing
Go测试模式包括表格驱动测试、子测试、基准测试、模糊测试和测试覆盖率。遵循TDD方法论，采用地道的Go实践。
Install with Tessl CLI
npx tessl i github:affaan-m/everything-claude-code --skill golang-testing63
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
32%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 identifies Go testing patterns and mentions TDD methodology, providing moderate specificity for the domain. However, it lacks explicit trigger guidance ('Use when...'), concrete action verbs, and natural user keywords, making it difficult for Claude to know when to select this skill over others.
Suggestions
Add a 'Use when...' clause with explicit triggers like 'Use when writing Go tests, creating _test.go files, or when user mentions Go unit testing, benchmarks, or test coverage'
Include concrete action verbs describing what the skill does: 'Generates table-driven tests, creates benchmark functions, implements fuzz tests'
Add natural user keywords in both Chinese and English: 'Go测试', 'unit test', 'go test命令', '_test.go'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (Go testing) and lists several specific patterns (table-driven tests, subtests, benchmarks, fuzz testing, coverage), but doesn't describe concrete actions like 'write', 'generate', or 'analyze'. | 2 / 3 |
Completeness | Describes what patterns are covered but completely lacks a 'Use when...' clause or any explicit trigger guidance for when Claude should select this skill. | 1 / 3 |
Trigger Term Quality | Contains relevant technical terms like '表格驱动测试' (table-driven tests), '基准测试' (benchmarks), '模糊测试' (fuzz testing), but missing common user phrases like 'Go test', 'unit test', '_test.go', or 'testing package'. | 2 / 3 |
Distinctiveness Conflict Risk | Specific to Go testing which provides some distinction, but could overlap with general Go development skills or generic testing skills without clearer boundaries. | 2 / 3 |
Total | 7 / 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, actionable Go testing skill with excellent executable code examples covering the full spectrum of Go testing patterns. The main weaknesses are moderate verbosity (explanatory sections Claude doesn't need) and the monolithic structure that could benefit from progressive disclosure to separate reference files. The TDD workflow and command references are particularly well done.
Suggestions
Remove or condense the 'When to Activate' section - Claude can infer when to apply testing patterns
Split advanced topics (fuzzing, benchmarks, HTTP testing) into separate reference files linked from a concise overview
Remove explanatory comments in code that describe what the code obviously does (e.g., '// Create request', '// Check response')
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is comprehensive but includes some unnecessary verbosity, such as the 'When to Activate' section and explanatory comments that Claude would already understand. The TDD workflow explanation could be more condensed. | 2 / 3 |
Actionability | Excellent executable code examples throughout - table-driven tests, benchmarks, fuzz tests, HTTP handler tests, and mocking patterns are all copy-paste ready with complete, runnable Go code. | 3 / 3 |
Workflow Clarity | The TDD Red-Green-Refactor workflow is clearly sequenced with explicit steps and verification points. The command reference section provides clear validation commands (go test -cover, -race, etc.). | 3 / 3 |
Progressive Disclosure | Content is well-organized with clear sections, but it's a monolithic document (~400 lines) that could benefit from splitting advanced topics (fuzzing, benchmarks, 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 (722 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.