golang-testing

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

Quality

—

Does it follow best practices?

Impact

—

No eval scenarios have been run

Securityby

Passed

No known issues

Quality

Content

65%

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 thorough, highly actionable Go-testing reference with excellent executable examples and clean section organization. Its main weaknesses are a monolithic, un-split structure with no progressive disclosure and an encyclopedia layout rather than a sequenced, checkpoint-driven workflow.

Suggestions

Split large peripheral topics (database testing, HTTP handler testing, fuzzing, integration testcontainers) into one-level-deep reference files under references/ and link them from SKILL.md to enable progressive disclosure.

Trim the inline reference to a concise overview plus quick-start so the base SKILL.md respects the token budget, pushing exhaustive examples into bundle files.

For the TDD and coverage workflows, add explicit validation checkpoints (e.g. 'run go test ./... and only refactor when green') to strengthen feedback loops.

Dimension	Reasoning	Score
Conciseness	Per-section explanations are lean and assume Claude's Go knowledge, but the SKILL.md is a ~960-line monolithic reference covering many topics, so the overall token footprint is large for inline content that could be slimmed or split.	2 / 3
Actionability	It provides abundant fully executable Go code (table-driven tests, interface mocks, httptest handlers, benchmarks, fuzzing) plus copy-paste-ready bash commands, making the guidance concrete and directly usable.	3 / 3
Workflow Clarity	The TDD section gives a clear 3-step sequence (write failing test → implement → refactor) and the quick-reference table aids navigation, but the skill is mostly an encyclopedia of topics rather than a sequenced multi-step workflow with explicit validation checkpoints.	2 / 3
Progressive Disclosure	No bundle files exist in references/, scripts/, or assets/, and the entire broad reference (mocking, HTTP, DB, benchmarks, fuzzing, integration, best practices) is inline in one well-sectioned SKILL.md rather than split into one-level-deep reference files.	2 / 3
	Total	9 / 12 Passed

Description

50%

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 scopes the skill to Go testing and TDD but is abstract, listing no concrete actions and providing no explicit 'Use when' trigger guidance. It is serviceable yet generic for a domain-specific skill.

Suggestions

Add concrete capabilities to the description, e.g. 'Write table-driven tests, mock interfaces with httptest, run benchmarks and fuzz tests, and track coverage for Go code.'

Append an explicit trigger clause, e.g. 'Use when writing or reviewing Go tests, improving coverage, adding benchmarks or fuzz tests, or fixing Go bugs.'

Include common user phrasings such as ユニットテスト, モック, and ベンチマーク to improve trigger-term coverage.

Dimension	Reasoning	Score
Specificity	The description names a clear domain ('Goコードの高品質を保証するためのテスト戦略') and a concrete practice ('テスト駆動開発'), but lists no specific concrete actions like table-driven tests, mocks, or benchmarks; it stops at the abstract goal rather than enumerating capabilities.	2 / 3
Completeness	It answers 'what' (a comprehensive testing strategy for TDD and Go quality) but provides no 'Use when...' or equivalent explicit trigger guidance, which the rubric caps at 2.	2 / 3
Trigger Term Quality	It includes relevant natural terms a user might say ('テスト', 'Go', 'テスト駆動開発') but omits common variations such as ユニットテスト, モック, ベンチマーク, or 'テストを書く/追加する'.	2 / 3
Distinctiveness Conflict Risk	Scoping to 'Go' testing gives it a distinct niche, but the generic 'テスト戦略' framing could still overlap with general testing skills, so it is not fully unambiguous.	2 / 3
	Total	8 / 12 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/everything-claude-code
Commit: 4130457

Reviewed: 4 days 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.