テスト駆動開発とGoコードの高品質を保証するための包括的なテスト戦略。
45
32%
Does it follow best practices?
Impact
Pending
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 natural user keywords. It identifies the domain (Go testing/TDD) but fails to specify what actions the skill performs or when Claude should invoke it. The description needs significant improvement to be useful for skill selection among many options.
Suggestions
Add a 'Use when...' clause with explicit triggers, e.g., 'Use when the user asks to write Go tests, generate table-driven tests, improve test coverage, or practice TDD in Go projects.'
List specific concrete actions the skill performs, e.g., 'Writes table-driven tests, generates mocks and stubs, creates benchmark tests, analyzes test coverage for Go packages.'
Include natural trigger terms users would say, such as 'go test', '_test.go', 'unit test', 'coverage', 'mock', 'benchmark', 'テストコード' to improve keyword matching.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description says 'comprehensive test strategy for test-driven development and Go code quality assurance' but does not list any concrete actions like 'write unit tests', 'generate table-driven tests', 'run test coverage analysis', etc. It remains abstract and vague. | 1 / 3 |
Completeness | The description partially addresses 'what' (test strategy for Go) but is very vague about it, and completely lacks a 'Use when...' clause or any explicit trigger guidance for when Claude should select this skill. | 1 / 3 |
Trigger Term Quality | Contains some relevant keywords like 'テスト駆動開発' (TDD), 'Go', and 'テスト戦略' (test strategy) that users might mention, but misses common variations like 'unit test', 'go test', 'coverage', 'benchmark', 'mock', or file extensions like '_test.go'. | 2 / 3 |
Distinctiveness Conflict Risk | The mention of Go and TDD provides some specificity, but 'テスト戦略' (test strategy) is broad enough to overlap with general testing skills or other Go development skills. It's somewhat distinguishable due to the Go + TDD combination but not clearly scoped. | 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 textbook inlined into a single SKILL.md, covering topics Claude already knows thoroughly (table-driven tests, httptest, benchmarks, fuzzing, mocking via interfaces). While the code examples are high quality and executable, the massive token cost provides almost no novel, project-specific guidance. The content would benefit enormously from being reduced to project-specific conventions and patterns, with standard Go testing knowledge assumed.
Suggestions
Reduce the content to only project-specific testing conventions, patterns, or non-obvious decisions — remove standard Go testing patterns that Claude already knows (table-driven tests, httptest, benchmarks, fuzzing basics).
Split the monolithic document into focused sub-files (e.g., MOCKING.md, BENCHMARKS.md, INTEGRATION_TESTS.md) and keep SKILL.md as a concise overview with links.
Add explicit workflow guidance with validation checkpoints, e.g., 'Before submitting: run `go test -race -cover ./...` and verify coverage meets X% threshold'.
Focus on what makes THIS project's testing unique — required coverage thresholds, specific mocking conventions, CI integration requirements, or custom test helpers already in the codebase.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | This is extremely verbose at ~500+ lines, covering nearly every Go testing concept Claude already knows well (table-driven tests, subtests, benchmarks, fuzzing, mocking patterns, httptest, etc.). Very little here is project-specific or novel — it's essentially a Go testing tutorial that wastes significant token budget. | 1 / 3 |
Actionability | The code examples are fully executable, concrete, and copy-paste ready throughout. Every pattern includes complete, runnable Go code with proper imports and clear usage demonstrations. | 3 / 3 |
Workflow Clarity | The TDD workflow (write test → implement → refactor) is mentioned but lacks validation checkpoints or feedback loops. The skill is more of a reference catalog than a guided workflow — steps for when to apply which testing strategy are implicit rather than explicit. | 2 / 3 |
Progressive Disclosure | This is a monolithic wall of text with no references to external files. All content — from basic assertions to fuzzing to database testing to benchmarks — is inlined in a single massive document that should be split into focused sub-documents with a concise overview. | 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 | |
5df943e
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.