CtrlK
BlogDocsLog inGet started
Tessl Logo

golang-naming

Go (Golang) naming conventions — covers packages, constructors, structs, interfaces, constants, enums, errors, booleans, receivers, getters/setters, functional options, acronyms, test functions, and subtest names. Use this skill when writing new Go code, reviewing or refactoring, choosing between naming alternatives (New vs NewTypeName, isConnected vs connected, ErrNotFound vs NotFoundError, StatusReady vs StatusUnknown at iota 0), debating Go package names (utils/helpers anti-patterns), or asking about Go naming best practices. Also trigger when the user mentions MixedCaps vs snake_case, ALL_CAPS constants, Get-prefix on getters, or error string casing. Do NOT use for general Go implementation questions that don't involve naming decisions.

89

1.34x
Quality

89%

Does it follow best practices?

Impact

86%

1.34x

Average score across 3 eval scenarios

SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

Quality

Content

78%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 well-structured reference skill: lean overview with strong Quick Reference and Common Mistakes tables, concrete Good/Bad examples, and clean one-level-deep disclosure into real reference files. The main slack is light over-explanation of Go basics and deferring most rule detail to references.

Suggestions

Trim rationale that re-states Go fundamentals Claude already knows (e.g., 'uppercase is exported, lowercase is unexported'; 'Go call sites always include the package name') — keep the rule and the naming payoff, drop the primer.

For actionability, add one or two complete copy-paste-ready snippets (e.g., a full enum block with the StatusUnknown-at-zero pattern and its String() method) so the most common cases are fully executable inline.

Make the apply-path an explicit short sequence with a checkpoint — e.g., '1. Spot the anti-pattern in the table → 2. Rename with gopls (see golang-gopls) → 3. Lint with revive/errname to confirm' — to nudge workflow_clarity to 5.

DimensionReasoningScore

Conciseness

The body is mostly lean — a compact Quick Reference table, terse Good/Bad code blocks, and a dense Common Mistakes table — but includes a few rationale sentences restating Go fundamentals Claude already knows (e.g., 'Capitalization controls visibility — uppercase is exported', 'Go call sites always include the package name'). It is efficient with only minor over-explanation that could be trimmed, not the padding seen at score 3.

4 / 5

Actionability

Provides concrete executable guidance — Good/Bad identifier blocks, a Quick Reference table with real examples, a Common Mistakes table with explicit fixes, and named linters (revive, predeclared, misspell, errname) — covering common cases well. It stops short of score 5 because the bulk of detailed rules are deferred to references and the inline snippets are illustrative patterns rather than complete copy-paste units.

4 / 5

Workflow Clarity

For a convention/reference skill, it gives a clear apply-path: identify a mistake via the Common Mistakes table, apply the fix, use the gopls-rename cross-reference for safe workspace-wide renaming, and enforce with linters. There is no explicit validate→fix→retry checkpoint loop, but none is required for a non-destructive naming reference, so the simple-skill guidance applies; minor explicitness keeps it at 4 rather than 5.

4 / 5

Progressive Disclosure

SKILL.md is a clear overview with a well-signaled Detailed Categories section pointing one level deep to five real reference files (packages-files.md, identifiers.md, functions-methods.md, types-errors.md, testing.md), each described by topic; references are flat (not nested) and navigation is easy, matching the score-5 anchor.

5 / 5

Total

17

/

20

Passed

Description

100%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 strong, third-person description that clearly states what the skill covers, when to trigger it, and when not to, with concrete naming-decision examples and natural trigger terms. It caps nothing and avoids vague fluff.

DimensionReasoningScore

Specificity

Enumerates many concrete naming categories — packages, constructors, structs, interfaces, constants, enums, errors, booleans, receivers, getters/setters, functional options, acronyms, test functions, subtests — plus specific decision examples (New vs NewTypeName, isConnected vs connected, ErrNotFound vs NotFoundError, StatusReady vs StatusUnknown at iota 0), giving comprehensive coverage rather than vague language.

5 / 5

Completeness

Explicitly answers both 'what' (naming conventions across all listed categories) and 'when' via a 'Use this skill when...' clause, an 'Also trigger when...' clause, and a 'Do NOT use for...' boundary, with concrete trigger phrases throughout.

5 / 5

Trigger Term Quality

Includes natural phrases a user would actually say — MixedCaps vs snake_case, ALL_CAPS constants, Get-prefix on getters, error string casing, utils/helpers anti-patterns — alongside synonyms (Go/Golang) and concrete naming alternatives, providing comprehensive keyword coverage.

5 / 5

Distinctiveness Conflict Risk

Occupies a clear niche (Go naming conventions only) with distinct triggers and an explicit exclusion ('Do NOT use for general Go implementation questions that don't involve naming decisions'), minimizing conflict with adjacent Go skills.

5 / 5

Total

20

/

20

Passed

Validation

93%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

metadata_field

'metadata' should map string keys to string values

Warning

Total

15

/

16

Passed

Repository
samber/cc-skills-golang
Reviewed

Table of Contents

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.