golang-testing

テスト駆動開発とGoコードの高品質を保証するための包括的なテスト戦略。

Quality

43%

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/ja-JP/skills/golang-testing/SKILL.md

Quality

Content

46%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 a well-organized, accurate, and highly actionable Go testing reference, but it is a ~960-line monolith that largely restates standard-library knowledge Claude already has and uses no progressive disclosure — everything is inlined in SKILL.md with no reference files. The TDD workflow is clearly sequenced but lacks explicit validation checkpoints.

Suggestions

Move the advanced sections (mocking, database testing, benchmarks, fuzzing, integration/testcontainers) into one-level-deep reference files (e.g. references/mocking.md, references/benchmarks.md) and keep SKILL.md as a concise overview with clearly signaled links.

Trim the standard-library patterns Claude already knows (basic assertions, t.Helper, subtests, go test flags) and keep only project-specific conventions or non-obvious guidance.

Add explicit validation checkpoints to the TDD workflow: run `go test ./...` after writing the failing test, again after implementation, and re-run before refactoring, with a fix-and-retry loop on failure.

Dimension	Reasoning	Score
Conciseness	The ~960-line body extensively re-documents standard-library knowledge Claude already has (table-driven tests, t.Helper(), httptest, -race, benchmark and fuzz syntax), spending most of its tokens on built-in knowledge. It is code-dense rather than prose-padded, so anchor 2 ('noticeably verbose; several unnecessary sections') fits better than anchor 1's padded-explanation style.	2 / 5
Actionability	Examples are concrete and mostly copy-paste executable (table-driven tests, httptest handlers, go test command flags, quick-reference table). Minor gaps keep it below anchor 5: several snippets depend on undefined symbols (Calculate, Process, testCase1) and the testcontainers example returns an undefined db.	4 / 5
Workflow Clarity	The TDD cycle is a clear numbered sequence (write failing test → implement → refactor) but validation checkpoints are implicit — the workflow never instructs running `go test ./...` between steps and there is no error-recovery loop. Not a destructive/batch skill, so the cap-at-3 rule doesn't bind; anchor 3 ('sequence present but checkpoints implicit') is the best fit.	3 / 5
Progressive Disclosure	No bundle files exist at all — the entire ~950-line reference (mocking, DB testing, benchmarks, fuzzing) is inlined in SKILL.md with good section headers but zero references. Anchor 2 ('content that clearly belongs in separate files is inlined') fits; anchor 3 presumes references exist but are poorly signaled, which is not the case here.	2 / 5
	Total	11 / 20 Passed

Description

40%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 identifies the Go-testing niche but is a single generic sentence: no concrete actions, no trigger clause, and no natural trigger phrases beyond 'Go' and 'TDD'. It reads as a topic label rather than a capability-and-trigger statement, capping completeness and specificity low.

Suggestions

Add a 'Use when...' clause (e.g. 'Use when writing or reviewing Go code, writing unit or table-driven tests, or running go test / coverage / benchmarks'), which is currently missing entirely.

Replace the generic "包括的なテスト戦略" with concrete actions such as writing table-driven tests, mocking interfaces, testing HTTP handlers with httptest, and running benchmarks/fuzzing.

Include natural trigger terms users would actually say: 'unit test', 'go test', 'test coverage', 'benchmark', 'fuzz', 'テストを書く'.

Dimension	Reasoning	Score
Specificity	The description names the Go testing domain but gives no concrete actions — "包括的なテスト戦略" (comprehensive testing strategy) is generic, and "保証する" (guarantee quality) is an over-claim. It matches anchor 2 ('names the domain but actions are minimal or generic') rather than anchor 3, which requires 1-2 concrete actions.	2 / 5
Completeness	The 'what' is vague ("comprehensive testing strategy") and there is no 'Use when...' clause or equivalent trigger guidance anywhere. Anchor 2 ('has a vague what and no when') is the closest fit; anchor 3's example has a clear, concrete 'what' which this lacks.	2 / 5
Trigger Term Quality	"Go", "テスト駆動開発" (TDD), and "テスト" are relevant domain keywords, but common natural variations users would say are missing: "unit test", "go test", "coverage", "benchmark", "write tests". Some relevant keywords missing common synonyms matches anchor 3; not 4 because coverage is thin.	3 / 5
Distinctiveness Conflict Risk	"Go" + testing is a clear niche with minimal overlap risk (only a generic testing skill could conflict). Mostly distinct with minor overlap risk matches anchor 4; not 5 because the description itself states no distinct triggers.	4 / 5
	Total	11 / 20 Passed

Validation

93%

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

Validation for skill structure

Criteria	Description	Result
skill_md_line_count	SKILL.md is long (960 lines); consider splitting into references/ and linking	Warning

	Total	15 / 16 Passed

Repository: affaan-m/ECC
Path: docs/ja-JP/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.