CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

golang-testing

Production-ready Golang tests — table-driven tests, testify suites and mocks, parallel tests, fuzzing, fixtures, goroutine leak detection with goleak, snapshot testing, code coverage, integration tests, idiomatic test naming. Use when writing or reviewing Go tests, choosing a testing approach, setting up Go test CI, or debugging flaky/slow tests. For testify-specific APIs see `samber/cc-skills-golang@golang-stretchr-testify`; for measurement methodology see `samber/cc-skills-golang@golang-benchmark`.

83

1.06x
Quality

90%

Does it follow best practices?

Impact

82%

1.06x

2 of 3 eval scenarios. Add 1 more for a full score.

SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

Quality

Content

86%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.

Highly actionable, well-structured content: executable code throughout, clearly sequenced operating modes, and exemplary progressive disclosure with seven real, one-level-deep reference files. The only deductions are minor verbosity (duplicated file-naming rationale, version-numbered feature notes) and mostly-implicit validation checkpoints in the mode workflows.

Suggestions

Collapse the file-naming guidance (lines 77-89): the prose rationale, the good/bad example, and the exception paragraph repeat the same rule — keep the example plus one sentence of rationale and fold the exception into the rule statement.

Move Go-version-gated details (synctest 1.25+/1.27+, ArtifactDir 1.26+, stdversion 1.27+) into a single versioned-compatibility section or a reference file so time-sensitive version numbers don't age the main body.

Add an explicit validation step to Debug and Write modes (e.g., "re-run the full test suite with -race to confirm the fix and no regressions") so each mode's sequence ends in a checkpoint rather than an implicit one.

DimensionReasoningScore

Conciseness

The body is largely lean and imperative with executable snippets, but has minor trimmable fat: the file-naming rationale is stated twice (prose paragraph at line 77 plus the good/bad example and exception paragraphs), and version-gated details (Go 1.25/1.26/1.27 sections) are time-sensitive content not placed in an "old patterns"/"deprecated" section, which the rubric flags. Not 5: those redundant and version-numbered passages mean not every token earns its place. Not 3: over-explanation is minor and isolated, not "several unnecessary explanations" — most sections are dense guidance Claude does not already know (assert-scope leaking, synctest semantics, ArtifactDir).

4 / 5

Actionability

Nearly every section carries copy-paste-ready code: table-driven test skeleton, goleak TestMain variants, synctest example, parallel-test pattern, fuzz seed corpus, ArtifactDir usage, plus a Quick Reference of exact `go test -run` command forms. This matches the score-5 anchor ("fully executable; copy-paste ready code or commands; specific examples cover the common cases"). Not 4: there is no gap in the concrete guidance for the common cases.

5 / 5

Workflow Clarity

The four Modes give clear sequencing — Write mode ("use `gotests` to scaffold table-driven tests, then enrich with edge cases and error paths"), Debug mode ("reproduce reliably, isolate the failing assertion, trace the root cause"), Audit mode (three named sub-agents merged into one gap report) — and the assert-leak section includes an explicit verification loop ("Verify with a deliberately-broken case: if `go test -v` shows ... the assert scope is leaking"). Not 5: checkpoints are mostly implicit (e.g., Debug mode gives phases but no explicit "verify the fix" step), so it matches "clear sequence with most checkpoints present; minor validation gaps" rather than the full validate→fix→retry anchor. Not 3: there is no missing-sequence or absent-validation problem severe enough for that anchor, and no destructive/batch operation triggers the cap.

4 / 5

Progressive Disclosure

The body is a genuine overview that delegates detail via clearly signaled, one-level-deep references — all seven referenced files (benchmarks.md, coverage.md, examples.md, helpers.md, http-testing.md, integration-testing.md, mocking.md) exist in references/ — and no reference chains deeper than one level; cross-skill pointers are also explicit. This matches the score-5 anchor. Not 4: there is no organization gap — each inline topic is core guidance while bulk detail (HTTP patterns, mocking, integration fixtures) lives in references.

5 / 5

Total

18

/

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: concrete capability list, explicit and multi-situation "Use when" triggers, third-person voice, and explicit delegation to sibling skills that reduces trigger conflicts. The only gap is a handful of missing natural synonyms (e.g., "golang", "unit tests").

DimensionReasoningScore

Specificity

The description lists many concrete capabilities — "table-driven tests, testify suites and mocks, parallel tests, fuzzing, fixtures, goroutine leak detection with goleak, snapshot testing, code coverage, integration tests, idiomatic test naming" — giving comprehensive coverage of the Go-testing domain with specific tooling named (testify, goleak). It uses third-person voice throughout. Not below 5: unlike the score-4 anchor, there are no meaningful coverage gaps across the domain's testing approaches.

5 / 5

Completeness

Explicitly answers both questions: what (the full capability list) and when ("Use when writing or reviewing Go tests, choosing a testing approach, setting up Go test CI, or debugging flaky/slow tests"), with concrete trigger phrases — a direct match for the score-5 anchor. It also adds scoping pointers to sibling skills, sharpening rather than diluting the answer.

5 / 5

Trigger Term Quality

Trigger phrase "Use when writing or reviewing Go tests, choosing a testing approach, setting up Go test CI, or debugging flaky/slow tests" covers natural user phrasing ("flaky tests", "slow tests", "Go test CI"). Not 5: a few natural synonyms users would say are missing (e.g., "golang", "unit tests", "_test.go"). Not 3: coverage clearly goes beyond "some relevant keywords" — it spans writing, reviewing, CI setup, and debugging use cases.

4 / 5

Distinctiveness Conflict Risk

The niche (Go testing) is clearly staked with distinct triggers, and conflict risk is actively reduced by delegation clauses — "For testify-specific APIs see `samber/cc-skills-golang@golang-stretchr-testify`; for measurement methodology see `samber/cc-skills-golang@golang-benchmark`" — so it is unlikely to fire for the wrong skill. Not 4: unlike the score-4 anchor, there is no notable overlap with closely related skills left ambiguous.

5 / 5

Total

19

/

20

Passed

Validation

93%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

metadata_field

'metadata' should map string keys to string values

Warning

Total

15

/

16

Passed

Repository

samber/cc-skills-golang

Path

skills/golang-testing/SKILL.md

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.