CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

golang-testing

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

1.36x
Quality

67%

Does it follow best practices?

Impact

86%

1.36x

Average score across 3 eval scenarios

SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/golang-testing/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

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

The body is highly actionable with complete, executable examples and a well-sequenced TDD workflow, but it is a monolithic reference that re-teaches Go testing fundamentals Claude already knows. Splitting per-topic references into bundle files and trimming standard-knowledge material would substantially improve token efficiency and structure.

Suggestions

Move topic-specific pattern libraries (mocking, benchmarks, fuzzing, HTTP handler testing, golden files) into separate reference files under references/ and keep SKILL.md as a concise overview with links.

Cut or drastically compress sections covering knowledge Claude already has (e.g., basic table-driven test syntax, t.Helper/t.TempDir basics) and keep only project-specific conventions and non-obvious guidance.

Complete the placeholder examples (the "// ..." Update/Delete subtests and the stubbed PostgresUserRepository.GetUser) so every code sample is copy-paste executable.

DimensionReasoningScore

Conciseness

At ~720 lines, the body extensively re-covers standard Go testing knowledge Claude already has (table-driven tests, subtests, t.Helper, t.TempDir, httptest, basic benchmark loops), with several sections that could be cut or trimmed to a brief project-specific convention list.

2 / 5

Actionability

Nearly all guidance is concrete, executable Go code and commands (complete table-driven tests, fuzz seeds, coverage commands, httptest handlers), with only minor gaps such as "// ..." placeholders in the Update/Delete subtests and a non-compiling stub in PostgresUserRepository.GetUser.

4 / 5

Workflow Clarity

The TDD RED-GREEN-REFACTOR sequence is clearly numbered with explicit verification checkpoints ("Run test - verify FAIL", "Run test - verify PASS"), but there is no error-recovery guidance for when a checkpoint fails unexpectedly.

4 / 5

Progressive Disclosure

Section headers are clear and well-organized, but the entire pattern library is inlined in a single ~720-line SKILL.md with no bundle files; content like the mocking, benchmark, fuzzing, and HTTP-testing references clearly belongs in separate reference files.

3 / 5

Total

13

/

20

Passed

Description

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

The description clearly communicates a Go-specific testing skill with concrete pattern names and appropriate third-person voice, but it entirely lacks a "when to use" trigger clause. Adding explicit activation conditions (e.g., "Use when writing or running Go tests, benchmarks, or fuzz tests") would raise both completeness and trigger quality.

Suggestions

Add an explicit trigger clause, e.g. "Use when writing or running tests in Go projects, or when the user mentions unit tests, go test, benchmarks, or fuzzing."

Include commonly used phrases users would actually say, such as "unit tests", "go test", and ".go test files", to broaden natural keyword coverage.

Mention additional capabilities the skill covers (mocking with interfaces, test helpers, golden files, HTTP handler testing) to make coverage more comprehensive.

DimensionReasoningScore

Specificity

Lists several specific patterns — "table-driven tests, subtests, benchmarks, fuzzing, and test coverage" — but omits others the skill actually covers (mocking, test helpers, golden files, HTTP handler testing), so coverage has minor gaps rather than being comprehensive.

4 / 5

Completeness

The "what" is clear (Go testing patterns with TDD), but there is no "Use when..." clause or equivalent explicit trigger guidance, which caps completeness at 3 per the rubric guidelines.

3 / 5

Trigger Term Quality

Good natural keyword coverage ("Go testing", "table-driven tests", "subtests", "benchmarks", "fuzzing", "test coverage", "TDD") that users would plausibly say, but misses common variations like "unit tests", "go test", and ".go files".

4 / 5

Distinctiveness Conflict Risk

Distinctly scoped to Go with idiomatic triggers like "table-driven tests" and Go-style "subtests"/"fuzzing", though generic terms such as "benchmarks" and "test coverage" leave minor overlap risk with a general testing skill.

4 / 5

Total

15

/

20

Passed

Validation

81%

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

CriteriaDescriptionResult

skill_md_line_count

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

Warning

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

relative_links

Relative link issues: 1 missing

Warning

Total

13

/

16

Passed

Repository

valeriibeck-star/claude-skills

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.