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

—

Does it follow best practices?

Impact

80%

1.12x

Average score across 3 eval scenarios

Securityby

Passed

No known issues

Quality

Content

77%

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

The content is highly actionable with executable code and a clear TDD workflow, but it is a monolithic 710-line document that recapitulates standard Go testing patterns and uses no progressive disclosure to split advanced material into reference files.

Suggestions

Move advanced sections (benchmarks, fuzzing, interface mocks, golden files) into separate reference files under references/ and link to them from a concise overview, keeping the most common patterns inline.

Trim the most standard examples (basic table-driven tests, simple subtests) to the minimal illustrative form, since Claude already knows idiomatic Go testing.

Add a short 'Quick start' section at the top with the single most common workflow, deferring the full pattern catalog to later sections or reference files.

Dimension	Reasoning	Score
Conciseness	Prose is lean and free of basic-concept padding, but the 710-line body restates many standard Go testing patterns Claude already knows (table-driven tests, subtests, basic benchmarks) and could be tightened; not a 3 because the volume exceeds what Claude needs, not a 1 because there is little conceptual fluff.	2 / 3
Actionability	Throughout the body are fully executable Go code blocks and concrete commands like `go test -coverprofile=coverage.out ./...` and `go tool cover -html=coverage.out`, copy-paste ready, matching the top anchor.	3 / 3
Workflow Clarity	The TDD RED-GREEN-REFACTOR cycle is an explicitly sequenced feedback loop with validation checkpoints (verify the test fails, verify it passes, refactor), plus a CI coverage gate, matching the clear-sequence-with-feedback-loops anchor.	3 / 3
Progressive Disclosure	Sections are well-organized with clear headers, but the body is monolithic with no bundle files and no one-level-deep references, and content that could live in separate files (benchmarks, fuzzing, interface mocks) is inline; not a 1 because organization is good, not a 3 because nothing is split or signaled.	2 / 3
	Total	10 / 12 Passed

Description

82%

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 is specific and trigger-rich with a clear Go-testing niche, but it omits any explicit "Use when..." guidance, leaving the activation conditions implicit and capping completeness.

Suggestions

Add an explicit 'Use when...' clause, e.g. 'Use when writing or improving Go tests, adding coverage, writing benchmarks/fuzz tests, or following a TDD workflow in Go.'

Lead with the strongest action verbs (e.g. 'Write table-driven tests, run benchmarks, add fuzz targets') to match the concrete verb-object style of the top anchor.

Keep the idiomatic-Go/TDD framing but ensure trigger terms cover common phrasings users say, such as 'Go test', 'test coverage', or 'flaky tests'.

Dimension	Reasoning	Score
Specificity	Lists multiple concrete testing activities — "table-driven tests, subtests, benchmarks, fuzzing, and test coverage" and "Follows TDD methodology" — rather than vague language, matching the multi-action anchor.	3 / 3
Completeness	Clearly answers what the skill does but provides no "Use when..." clause or equivalent explicit trigger guidance, which per the guidelines caps completeness at 2; it is not a 3 because the when is entirely missing rather than explicit.	2 / 3
Trigger Term Quality	Covers natural terms a Go developer would actually say — "Go testing", "table-driven tests", "subtests", "benchmarks", "fuzzing", "test coverage", "TDD" — with good breadth of common variations.	3 / 3
Distinctiveness Conflict Risk	"Go testing patterns" is a clear, narrow niche with distinct triggers unlikely to fire for unrelated skills; it is not a 2 because the Go-specific scope is unambiguous.	3 / 3
	Total	11 / 12 Passed

Validation

87%

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 — 14 / 16 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
relative_links	Relative link issues: 1 missing	Warning

	Total	14 / 16 Passed

Repository: ysyecust/everything-claude-code
Commit: a9cbecb

Reviewed: 1 day 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.