golang-patterns

Idiomatic Go patterns, best practices, and conventions for building robust, efficient, and maintainable Go applications.

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.

This is a thorough, highly actionable Go patterns reference with executable code and concrete tooling commands, but it is a long monolithic document that recaps some well-known patterns and lacks progressive disclosure via split-out reference files.

Suggestions

Move the linter configuration, standard project layout, and extended pattern catalogs into separate reference files (e.g. LINTING.md, LAYOUT.md) and link to them from SKILL.md to apply progressive disclosure.

Trim or consolidate Good/Bad pairs where a single canonical example plus a one-line anti-pattern note conveys the same lesson, reducing token cost.

For the build/test/lint workflow, add an explicit sequenced checklist with a validation checkpoint (e.g. 'run go vet and golangci-lint; fix and re-run before committing') to raise workflow clarity.

Dimension	Reasoning	Score
Conciseness	The body is mostly efficient with executable examples, but at ~670 lines it catalogs several patterns Claude already knows (worker pools, context, sync.Pool, strings.Builder) and the Good/Bad对比 roughly doubles code volume where a single canonical example would suffice.	2 / 3
Actionability	It provides fully executable Go code throughout plus concrete commands ('go build ./...', 'go test -race ./...', 'golangci-lint run') and a copy-paste-ready linter config, leaving no ambiguity about what to do.	3 / 3
Workflow Clarity	Sections are well organized by topic and there is a 'When to Activate' list, but this is a reference catalog rather than a sequenced multi-step workflow, and no validation checkpoints are present for the build/test/lint cycle.	2 / 3
Progressive Disclosure	Internal sections are clearly organized, but everything lives in a single ~670-line SKILL.md with no bundle files or one-level-deep references; material such as the full linter config, project layout, and detailed pattern catalog could be split out.	2 / 3
	Total	9 / 12 Passed

Description

57%

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 conveys a clear Go-specific niche and scope but relies on abstract category nouns instead of concrete actions and omits any explicit 'when to use' trigger clause. It is solid but not exemplary.

Suggestions

Replace abstract nouns with concrete verbs, e.g. 'Write, review, and refactor idiomatic Go code following best-practice patterns for error handling, concurrency, and package design.'

Add an explicit trigger clause such as 'Use when writing, reviewing, or refactoring Go (golang) code, or designing Go packages and modules.'

Include common user terms like 'golang' and 'Go code' alongside 'Go' to improve trigger coverage.

Dimension	Reasoning	Score
Specificity	Names the Go domain and categories ('patterns, best practices, and conventions for building robust, efficient, and maintainable Go applications') but uses abstract nouns rather than concrete verbs like 'extract' or 'refactor', so it is not a comprehensive list of specific actions.	2 / 3
Completeness	It clearly answers 'what' the skill does but lacks any 'Use when…' clause or equivalent explicit trigger guidance, which per the judging guidelines caps completeness at 2.	2 / 3
Trigger Term Quality	Includes natural terms a user might say ('Go patterns', 'best practices', 'Go applications') but omits common variations such as 'golang', 'Go code', or 'refactoring', so coverage is partial.	2 / 3
Distinctiveness Conflict Risk	The repeated Go-specific framing ('Idiomatic Go patterns', 'Go applications') carves out a clear niche with distinct triggers that are unlikely to fire for non-Go skills.	3 / 3
	Total	9 / 12 Passed

Validation

87%

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

Validation for skill structure

Criteria	Description	Result
skill_md_line_count	SKILL.md is long (677 lines); consider splitting into references/ and linking	Warning
metadata_version	'metadata.version' is missing	Warning

	Total	14 / 16 Passed

Repository: ysyecust/everything-claude-code
Commit: a9cbecb

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.