golang-testing

Go测试模式包括表格驱动测试、子测试、基准测试、模糊测试和测试覆盖率。遵循TDD方法论，采用地道的Go实践。

Quality

67%

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

Fix and improve this skill with Tessl

tessl review fix ./docs/zh-CN/skills/golang-testing/SKILL.md

Quality

Content

63%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 thorough, highly actionable Go testing reference with executable examples and a well-sequenced TDD workflow including validation steps. Its weaknesses are verbosity (redundant TDD basics), a monolithic 715-line structure with no progressive disclosure into reference files, and a couple of non-compiling code snippets.

Suggestions

Trim the step-by-step TDD calculator walkthrough and other basics Claude already knows; keep only the Go-specific idioms (t.Helper, t.Cleanup, t.TempDir, subtests).

Split advanced material (benchmarks, fuzzing, HTTP handler testing, CI/CD integration) into reference files (e.g. BENCHMARKS.md, FUZZING.md, CI.md) and keep SKILL.md as a concise overview with clearly signaled one-level-deep links.

Fix non-executable snippets (give PostgresUserRepository.GetUser a real body or drop the production-implementation block) and remove the obsolete `tt := tt` capture idiom for Go 1.22+.

Dimension	Reasoning	Score
Conciseness	The body is mostly dense, useful Go code templates, but the ~50-line step-by-step TDD calculator walkthrough ("RED → 首先编写一个失败的测试... REFACTOR → 改进代码") explains red-green-refactor concepts Claude already knows, and the best-practices prose restates standard knowledge; it could be tightened.	3 / 5
Actionability	Nearly all guidance is executable copy-paste code with concrete commands (go test -race -coverprofile=coverage.out, -benchmem, -fuzztime=30s, httptest patterns); minor gaps exist, e.g. PostgresUserRepository.GetUser has only a comment body so that snippet will not compile, and the `tt := tt` capture idiom is pre-Go 1.22.	4 / 5
Workflow Clarity	The core TDD workflow is clearly sequenced with explicit validation checkpoints ("Run test - verify FAIL", "Run test - verify PASS", refactor then re-verify), matching the clear-sequence-with-most-checkpoints anchor; the remaining sections are pattern references that don't require workflows, so it doesn't reach the feedback-loop-rich score-5 anchor.	4 / 5
Progressive Disclosure	The body has 13 clear, well-organized ## sections aiding navigation, but it is a ~715-line monolithic SKILL.md with zero external reference files — benchmarking, fuzzing, HTTP handler testing, and CI/CD content that clearly belongs in separate reference files is inlined, fitting the 'structure present but content that should be separate is inline' anchor.	3 / 5
	Total	14 / 20 Passed

Description

71%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 specific, well-scoped description that enumerates concrete Go testing capabilities in third person, but it lacks any 'when to use' trigger clause, which both caps completeness and slightly weakens its discoverability. Adding a Use-when clause and a few more natural trigger terms (unit tests, go test) would lift it to top tier.

Suggestions

Add an explicit trigger clause, e.g. "Use when writing Go tests, running go test, or following a TDD workflow in Go."

Include additional natural trigger terms users actually say: 单元测试/unit tests, go test command, mocking, test coverage.

Mention the Go version context for fuzzing (Go 1.18+) or keep it neutral to avoid time-sensitivity in the description.

Dimension	Reasoning	Score
Specificity	The description lists multiple specific concrete capabilities — "表格驱动测试、子测试、基准测试、模糊测试和测试覆盖率" (table-driven tests, subtests, benchmarks, fuzz testing, test coverage) plus TDD methodology — comprehensively covering the skill's domain, matching the score-5 anchor.	5 / 5
Completeness	The 'what' is clearly stated (Go testing patterns enumerated), but there is no 'Use when...' clause or equivalent explicit trigger guidance; the rubric guideline explicitly caps completeness at 3 for this.	3 / 5
Trigger Term Quality	Natural terms users would say are present (Go测试, 基准测试, 模糊测试, TDD, 测试覆盖率), giving good coverage, but common variations like 单元测试/unit tests, `go test`, or mocking are missing, so it falls short of the comprehensive-synonyms anchor.	4 / 5
Distinctiveness Conflict Risk	"Go测试模式" names the language explicitly with Go-specific patterns, giving a clear niche with minimal conflict; minor overlap risk remains with generic TDD or unit-testing skills since '遵循TDD方法论' is language-agnostic.	4 / 5
	Total	16 / 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 (723 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: affaan-m/ECC
Path: docs/zh-CN/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.