テスト駆動開発とGoコードの高品質を保証するための包括的なテスト戦略。
45
32%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./docs/ja-JP/skills/golang-testing/SKILL.mdQuality
Discovery
22%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This description is too abstract and lacks concrete actions, explicit trigger conditions, and sufficient keyword coverage. It identifies the domain (Go, TDD) but fails to specify what the skill actually does or when Claude should select it. Adding specific capabilities and a 'Use when...' clause would significantly improve its effectiveness.
Suggestions
Add a 'Use when...' clause specifying triggers, e.g., 'Use when the user asks about writing Go tests, test-driven development, table-driven tests, mocking, or test coverage in Go projects.'
List specific concrete actions the skill performs, e.g., 'Generates table-driven tests, creates mock implementations, writes benchmark tests, ensures test coverage for Go packages.'
Include common natural language variations users might use, such as 'go test', 'unit test', 'テストコード', 'カバレッジ', 'モック', 'TDD' in both Japanese and English.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description says '包括的なテスト戦略' (comprehensive test strategy) and mentions TDD and Go code quality, but does not list any concrete actions like 'write unit tests', 'generate test files', 'run test suites', or 'create mocks'. It remains abstract and vague about what the skill actually does. | 1 / 3 |
Completeness | The description partially addresses 'what' (test strategy for Go) but is vague about it, and completely lacks any 'when' clause or explicit trigger guidance. There is no 'Use when...' or equivalent instruction for Claude to know when to select this skill. | 1 / 3 |
Trigger Term Quality | It includes some relevant keywords like 'テスト駆動開発' (TDD), 'Go', and 'テスト' (test), which users might naturally mention. However, it misses common variations like 'unit test', 'table-driven test', 'go test', 'coverage', 'mock', or English equivalents that users might use. | 2 / 3 |
Distinctiveness Conflict Risk | The mention of Go and TDD provides some specificity that distinguishes it from generic testing skills, but 'テスト戦略' (test strategy) is broad enough that it could overlap with other testing-related or Go development skills. | 2 / 3 |
Total | 6 / 12 Passed |
Implementation
42%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill is essentially a comprehensive Go testing tutorial/reference that covers nearly every testing concept in Go. While the code examples are excellent and fully executable, the content is far too verbose for a skill file—Claude already knows standard Go testing patterns like table-driven tests, subtests, benchmarks, and mocking. The skill would benefit enormously from being trimmed to only project-specific conventions or non-obvious patterns, with the reference material moved to separate files.
Suggestions
Reduce the content to only project-specific testing conventions and non-obvious patterns that Claude wouldn't already know (e.g., specific project test infrastructure, custom helpers, required coverage thresholds). Remove standard Go testing knowledge like basic assertions, table-driven tests, and benchmark syntax.
Split the reference material into separate files (e.g., MOCKING.md, BENCHMARKS.md, HTTP_TESTING.md) and keep SKILL.md as a concise overview with links, improving progressive disclosure.
Add a clear workflow with validation checkpoints, such as: 'Run tests → Check coverage meets X% → Run race detector → Verify CI passes' with explicit feedback loops for failures.
Remove explanatory content like 'テスト駆動開発(TDD)ワークフロー' descriptions and focus on project-specific rules (e.g., 'All new code must have table-driven tests', 'Use build tags for integration tests').
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | This is extremely verbose at ~500+ lines, covering nearly every Go testing concept (TDD, table-driven tests, subtests, mocking, HTTP testing, database testing, benchmarks, fuzzing, parallelization, coverage, etc.). Most of this is standard Go knowledge that Claude already knows well. The skill reads like a Go testing tutorial/reference manual rather than a concise skill adding novel information. | 1 / 3 |
Actionability | All code examples are fully executable, concrete, and copy-paste ready. Commands are specific with proper flags. The examples cover real patterns with complete implementations including both production and test code. | 3 / 3 |
Workflow Clarity | The TDD workflow (write test → implement → refactor) is clearly stated, and the 'when to activate' section provides context. However, there are no validation checkpoints or feedback loops for the overall testing process—no guidance on what to do when tests fail in CI, no verification steps for coverage thresholds, and the workflow is more of a pattern catalog than a sequenced process. | 2 / 3 |
Progressive Disclosure | The entire content is a monolithic wall of text with no references to external files or any content splitting. Everything from basic assertions to fuzzing to database testing is inlined in a single massive document, with no bundle files to support progressive disclosure. | 1 / 3 |
Total | 7 / 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 (960 lines); consider splitting into references/ and linking | Warning |
Total | 10 / 11 Passed | |
841beea
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.