Name: golang-code-style
Rating: 84 (1 reviews)
Author: samber

golang-code-style

Golang code style conventions — line length and breaking, variable declarations, control flow clarity, when comments help vs hurt. Use when writing or reviewing Go code, asking about style or clarity, or establishing project coding standards. Not for naming conventions (→ See `samber/cc-skills-golang@golang-naming` skill), linter configuration (→ See `samber/cc-skills-golang@golang-lint` skill), or doc comments (→ See `samber/cc-skills-golang@golang-documentation` skill).

1.27x

Quality

81%

Does it follow best practices?

Impact

84%

1.27x

Average score across 3 eval scenarios

Securityby

Passed

No findings from the security scan

Quality

Content

76%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 content is highly actionable with executable examples and a lean, rule-dense format, and it uses one-level-deep references well. Its main weakness is the parallelized review workflow, which lacks validation checkpoints, capping workflow clarity at 3.

Suggestions

Add an explicit validation/verification step to the 'Parallelizing Code Style Reviews' workflow (e.g., 'After merging findings, re-check each violation against the cited rule and the surrounding code to confirm it is not a false positive before reporting').

Trim the Philosophy proverbs and redundant explanatory clauses (e.g., the 'A little copying...' and 'Reflection is never clear' aphorisms) to push conciseness toward the lean anchor 5.

Consider splitting the longer inline sections (e.g., Control Flow or Code Organization) into references/ files to reduce SKILL.md length and improve progressive disclosure.

Dimension	Reasoning	Score
Conciseness	The body is dense with rules and executable Go examples and assumes Claude's competence (no explaining what Go/slices are), but the Philosophy proverbs and a few explanatory clauses could be trimmed, so it sits at efficient-but-not-fully-lean anchor 4 rather than 5.	4 / 5
Actionability	Throughout the body are copy-paste-ready, executable Go examples (line breaking, slice/map init, early return, default-then-override switch, named booleans, range loops) covering the common style cases, matching anchor 5.	5 / 5
Workflow Clarity	The only multi-step workflow is the "Parallelizing Code Style Reviews" section ("use up to 5 parallel sub-agents... and merge their findings"), a batch review with no validation/verification checkpoint, which caps it at anchor 3 per the batch-operation guideline.	3 / 5
Progressive Disclosure	Structure is good with clear section headers and well-signaled one-level-deep references ("[Details](./references/details.md)" — verified to exist) for two topics, but most content remains inline in a fairly long SKILL.md rather than being split out, keeping it at anchor 4 instead of 5.	4 / 5
	Total	16 / 20 Passed

Description

87%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 is strong: it states concrete capabilities, gives natural trigger phrases, answers both what and when, and explicitly disambiguates from sibling skills via negative boundary guidance. The only minor gap is that the capability list under-represents the body's full breadth.

Dimension	Reasoning	Score
Specificity	Quotes "line length and breaking, variable declarations, control flow clarity, when comments help vs hurt" — several concrete style domains, but the description omits topics the body covers (function design, value-vs-pointer, string handling, type conversions), so it falls short of the comprehensive anchor 5.	4 / 5
Completeness	Explicitly answers what ("Golang code style conventions — line length and breaking, variable declarations...") and when ("Use when writing or reviewing Go code, asking about style or clarity...") with concrete trigger phrases, matching the anchor 5 example.	5 / 5
Trigger Term Quality	Quotes "Use when writing or reviewing Go code, asking about style or clarity, or establishing project coding standards" — strong natural phrases users would say, but lacks common synonyms/extensions like "Go style guide" or "gofmt", keeping it just below the comprehensive anchor 5.	4 / 5
Distinctiveness Conflict Risk	The "Not for naming conventions (→ See ...), linter configuration (→ See ...), or doc comments (→ See ...)" clause carves a clear niche with explicit pointers to sibling skills, giving minimal conflict risk as in anchor 5.	5 / 5
	Total	18 / 20 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
metadata_field	'metadata' should map string keys to string values	Warning
relative_links	Relative link issues: 1 missing	Warning

	Total	14 / 16 Passed

Repository: samber/cc-skills-golang
Path: skills/golang-code-style/SKILL.md
Commit: 19a0626

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.