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.

85

1.00x
Quality

86%

Does it follow best practices?

Impact

75%

1.00x

Average score across 3 eval scenarios

SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

Quality

Content

72%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.

Well-structured, highly actionable naming reference with excellent progressive disclosure via five clearly signaled reference files. Its main weakness is redundancy across the Quick Reference, prose sections, and Common Mistakes table, and the absence of an in-skill validation checkpoint for the destructive rename workflow it defers elsewhere.

Suggestions

Collapse the redundancy between the Quick Reference table, the MixedCaps/Avoid Stuttering/Frequently Missed sections, and the Common Mistakes table — keep the table as the index and let prose add only the rationale each row lacks.

Add a short in-skill validation step for applying a naming fix (e.g. 'after rename, run `go build ./...` and `golangci-lint run` before committing') instead of fully deferring it to the gopls/refactoring skills.

Trim rationale sentences that restate what the example already shows (e.g. the explanatory clauses after some ✓/✗ blocks) to reduce token cost without losing the rule.

DimensionReasoningScore

Conciseness

Mostly efficient but noticeably redundant: the Quick Reference table, the MixedCaps/Avoid Stuttering/Frequently Missed sections, and the 24-row Common Mistakes table re-state the same rules (e.g. ALL_CAPS, stuttering, getters) three times, so the body could be tightened.

3 / 5

Actionability

Provides extensive concrete ✓ Good / ✗ Bad code blocks, a worked Quick Reference table with real examples, and a Common Mistakes table with explicit fixes — specific, copy-paste-ready guidance covering the common naming cases.

5 / 5

Workflow Clarity

This is a reference document rather than a sequenced workflow, and applying naming fixes is a destructive/batch rename that the skill defers to the gopls skill with no in-skill validation checkpoint, so workflow clarity is capped at 3.

3 / 5

Progressive Disclosure

A clear overview body points to five real one-level-deep reference files (packages-files.md, identifiers.md, functions-methods.md, types-errors.md, testing.md), each well-signaled with a description under 'Detailed Categories', making navigation easy.

5 / 5

Total

16

/

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, comprehensive description that clearly states what the skill covers, when to trigger it, and when not to. It uses third person, includes natural trigger terms, and draws a sharp boundary against general Go implementation questions.

DimensionReasoningScore

Specificity

Lists multiple concrete coverage areas (packages, constructors, structs, interfaces, constants, enums, errors, booleans, receivers, getters/setters, functional options, acronyms, test functions, subtests) and concrete actions (writing, reviewing/refactoring, choosing between 'New vs NewTypeName', debating 'utils/helpers' anti-patterns), giving comprehensive coverage.

5 / 5

Completeness

Explicitly answers both 'what' (Go naming conventions covering a named list of element types) and 'when' ('Use this skill when...', 'Also trigger when the user mentions...') with concrete trigger phrases and a negative boundary.

5 / 5

Trigger Term Quality

Includes natural phrases users would actually say — 'MixedCaps vs snake_case', 'ALL_CAPS constants', 'Get-prefix on getters', 'error string casing', 'Go naming best practices' — with synonyms and variant phrasings.

5 / 5

Distinctiveness Conflict Risk

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

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.