CtrlK
BlogDocsLog inGet started
Tessl Logo

golang-testing

テスト駆動開発とGoコードの高品質を保証するための包括的なテスト戦略。

45

Quality

32%

Does it follow best practices?

Impact

No eval scenarios have been run

SecuritybySnyk

Passed

No known issues

Optimize this skill with Tessl

npx tessl skill review --optimize ./docs/ja-JP/skills/golang-testing/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

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.

DimensionReasoningScore

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').

DimensionReasoningScore

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.

Validation10 / 11 Passed

Validation for skill structure

CriteriaDescriptionResult

skill_md_line_count

SKILL.md is long (960 lines); consider splitting into references/ and linking

Warning

Total

10

/

11

Passed

Repository
affaan-m/everything-claude-code
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.