golang-testing

Go testing patterns including table-driven tests, subtests, benchmarks, fuzzing, and test coverage. Follows TDD methodology with idiomatic Go practices.

1.12x

Quality

53%

Does it follow best practices?

Impact

80%

1.12x

Average score across 3 eval scenarios

Securityby

Passed

No known issues

Optimize this skill with Tessl

npx tessl skill review --optimize ./docs/zh-TW/skills/golang-testing/SKILL.md

Quality

Content

57%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

This skill provides excellent, actionable Go testing patterns with fully executable code examples covering a wide range of testing scenarios. Its main weaknesses are its monolithic structure (everything in one large file with no progressive disclosure) and moderate verbosity—some sections explain concepts Claude already knows (basic TDD steps, what table-driven tests are). The content would benefit significantly from being split into focused sub-files with a concise overview in SKILL.md.

Suggestions

Split the content into separate files (e.g., BENCHMARKS.md, FUZZING.md, MOCKING.md, HTTP_TESTING.md) and make SKILL.md a concise overview with links to each topic.

Remove explanatory prose like '用於撰寫可靠、可維護測試的完整 Go 測試模式' and the TDD step-by-step walkthrough comments—Claude knows TDD and Go testing basics.

Add explicit validation checkpoints to the workflow, e.g., 'After writing tests, run `go test -race -cover ./...` and verify coverage meets targets before proceeding.'

Dimension	Reasoning	Score
Conciseness	The skill is quite long (~400+ lines) and includes many patterns that an experienced Go developer (or Claude) would already know. The TDD step-by-step walkthrough with comments like '步驟 1: 定義介面/簽章' is verbose. However, the code examples themselves are lean and well-structured, and the content serves as a comprehensive reference. Some sections like the basic Add example and the CI/CD YAML could be trimmed.	2 / 3
Actionability	Every section provides fully executable, copy-paste ready Go code with concrete examples. Commands are specific (e.g., `go test -bench=BenchmarkProcess -benchmem`), test patterns include complete function signatures, and even the CI/CD section has a working GitHub Actions YAML. The code is real Go, not pseudocode.	3 / 3
Workflow Clarity	The TDD RED-GREEN-REFACTOR cycle is clearly sequenced with explicit steps and verification commands. However, there are no validation checkpoints or feedback loops for the broader testing workflow (e.g., what to do when coverage drops, how to handle fuzz test failures, no explicit 'verify before committing' steps). The coverage check in CI is a good touch but the overall workflow guidance is implicit rather than explicit.	2 / 3
Progressive Disclosure	This is a monolithic wall of content with no references to external files. All patterns—table-driven tests, subtests, benchmarks, fuzzing, HTTP testing, mocking, golden files, CI/CD—are inlined in a single massive document. For a skill this comprehensive, content should be split into separate reference files (e.g., BENCHMARKS.md, FUZZING.md, MOCKING.md) with the SKILL.md serving as an overview with navigation links.	1 / 3
	Total	8 / 12 Passed

Description

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 does well at listing specific Go testing capabilities and is clearly distinguishable from other skills. However, it critically lacks any 'Use when...' guidance, which would help Claude know when to select this skill. Adding natural user trigger terms and explicit selection criteria would significantly improve its effectiveness.

Suggestions

Add a 'Use when...' clause such as 'Use when the user asks about writing Go tests, running benchmarks, generating test coverage, or following TDD in Go.'

Include additional natural trigger terms users might say, such as 'unit test', 'go test', '_test.go', 'testing package', 'mock', or 'test helpers'.

Dimension	Reasoning	Score
Specificity	Lists multiple specific concrete actions/patterns: table-driven tests, subtests, benchmarks, fuzzing, test coverage, and TDD methodology. These are all concrete, identifiable testing techniques.	3 / 3
Completeness	Describes what the skill covers (Go testing patterns) but completely lacks a 'Use when...' clause or any explicit trigger guidance for when Claude should select this skill. Per rubric guidelines, missing 'Use when' should cap completeness at 2, and since the 'when' is entirely absent, this scores a 1.	1 / 3
Trigger Term Quality	Includes good domain-specific terms like 'table-driven tests', 'subtests', 'benchmarks', 'fuzzing', 'test coverage', and 'TDD', but misses common natural user phrases like 'write tests', 'unit test', 'go test', '_test.go', or 'testing package'.	2 / 3
Distinctiveness Conflict Risk	Clearly scoped to Go testing specifically, with distinct triggers like 'table-driven tests', 'fuzzing', and 'Go practices' that are unlikely to conflict with general testing skills or other language-specific testing skills.	3 / 3
	Total	9 / 12 Passed

Validation

90%

Warnings & errors only

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

Repository: ysyecust/everything-claude-code
Commit: 79cc4e3

Reviewed: 3 months ago

Table of Contents

Discovery Implementation Validation

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.