golang-testing

Go testing patterns including table-driven tests, subtests, benchmarks, fuzzing, and test coverage. Follows TDD methodology with idiomatic Go practices. Use when writing Go tests — table-driven cases, subtests, benchmarks, fuzzing, or coverage.

Quality

81%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Quality

Content

70%Weight 40%Scale 1-5

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

A well-organized, highly actionable reference whose TDD workflow is exemplary, but it is a monolithic ~720-line document that re-teaches standard Go testing knowledge Claude already has instead of splitting advanced material into reference files. Splitting it and trimming redundant examples would substantially improve token efficiency.

Suggestions

Split advanced sections (benchmarks, fuzzing, HTTP handler testing, CI/CD) into reference files (e.g. references/benchmarks.md, references/fuzzing.md) and keep SKILL.md as a concise overview with the TDD workflow and core table-driven pattern.

Trim content Claude already knows — t.Helper(), httptest basics, standard go test flags — down to one-line reminders, and cut redundant variants (three benchmark styles, two fuzz examples) to one canonical example each.

Fix non-executable placeholders: give PostgresUserRepository.GetUser a compiling body and either complete or remove the empty Update/Delete subtest stubs.

Dimension	Reasoning	Score
Conciseness	Prose is lean and mostly code, but the ~720-line body extensively documents standard Go idioms Claude already knows (table-driven tests, t.Helper(), httptest, -race, -benchmem) and includes redundant variants (three benchmark examples, two fuzz examples) that could be tightened. Not 4: the issue is the overall volume of already-known material, not minor instances of over-explanation.	3 / 5
Actionability	Nearly all snippets are executable with concrete commands ('go test -coverprofile=coverage.out', 'go test -fuzz=FuzzParseJSON -fuzztime=30s'), but a few are non-executable placeholders: PostgresUserRepository.GetUser has a comment-only body, and the Update/Delete subtests are empty stubs. Not 5: these gaps keep it from fully copy-paste ready; not 3: the guidance is concrete with only minor gaps.	4 / 5
Workflow Clarity	The RED-GREEN-REFACTOR cycle is laid out as a numbered step-by-step with explicit validation checkpoints ('Run test - verify FAIL', 'Run test - verify PASS', 'Refactor if needed, verify tests still pass') forming a built-in feedback loop. No destructive or batch operations are involved, so no cap applies. Not 4: checkpoints are explicit, not merely present.	5 / 5
Progressive Disclosure	Section headers are well-organized, but the entire 720-line body is inline with zero reference files — benchmarks, fuzzing, HTTP handler testing, and CI/CD integration clearly belong in separate reference files. Not 4: most content is not appropriately placed for a file this size; not 2: structure is not minimal, headers are clear and navigable.	3 / 5
	Total	15 / 20 Passed

Description

92%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong description that concretely enumerates capabilities and pairs them with an explicit, trigger-rich 'Use when' clause in third person. Its only weakness is missing common synonyms a user might naturally say, such as 'unit tests' or 'mocking'.

Suggestions

Add natural synonyms users commonly say, e.g. 'Use when writing unit tests, test files, or mocks in Go', to lift trigger-term coverage.

Optionally mention mocking/httptest patterns in the description since they are a significant part of the skill body but absent from the description.

Dimension	Reasoning	Score
Specificity	The description lists multiple specific concrete actions — 'table-driven tests, subtests, benchmarks, fuzzing, and test coverage' — giving comprehensive coverage of the Go testing domain with no noticeable gaps, matching the anchor-5 breadth.	5 / 5
Completeness	Explicitly answers both 'what' ('Go testing patterns including table-driven tests, subtests, benchmarks, fuzzing, and test coverage') and 'when' ('Use when writing Go tests — table-driven cases, subtests, benchmarks, fuzzing, or coverage') with concrete trigger phrases, mirroring the anchor-5 example.	5 / 5
Trigger Term Quality	Good natural keyword coverage ('writing Go tests', 'benchmarks', 'fuzzing', 'coverage', 'TDD'), but common user synonyms like 'unit tests', 'test files', or 'mocking' are missing. Not 3 because coverage is solid rather than partial; not 5 because synonym-level breadth is absent.	4 / 5
Distinctiveness Conflict Risk	Clearly scoped to Go testing with distinct triggers (Go, table-driven tests, fuzzing); minimal overlap risk with general testing or other language skills. Not 4 because no meaningful overlap with closely related skills is evident.	5 / 5
	Total	19 / 20 Passed

Validation

81%

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 — 13 / 16 Passed

Validation for skill structure

Criteria	Description	Result
skill_md_line_count	SKILL.md is long (722 lines); consider splitting into references/ and linking	Warning
metadata_version	'metadata.version' is missing	Warning
relative_links	Relative link issues: 1 missing	Warning

	Total	13 / 16 Passed

Repository: affaan-m/ECC
Path: skills/golang-testing/SKILL.md
Commit: c70874f

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.