naming

Evaluate and improve names in code using naming as a design diagnostic. Use when the user asks to "name this", "rename", "review naming", "what should I call", struggles to name something, or when a code review surfaces vague or misleading names.

Quality

87%

Does it follow best practices?

Impact

—

No eval scenarios have been run

Securityby

Passed

No known issues

Quality

Content

85%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

This is a strong, well-structured skill that provides highly actionable naming guidance with excellent concrete examples and a clear output format. The two modes (Review and Design) give Claude distinct workflows for different situations. The main weakness is moderate redundancy in examples across sections (Strunk's Rule 12 repeats earlier tables) and some explanatory text about principles that Claude likely already understands.

Suggestions

Remove the Strunk's Rule 12 table or merge its unique entries into the existing Before/After tables to eliminate redundancy.

Trim the Bloch and Evans sections to just the actionable rules — Claude doesn't need the framing about who these people are or why these principles matter.

Dimension	Reasoning	Score
Conciseness	The skill is well-structured but somewhat verbose for what Claude needs. The before/after tables are valuable but there's redundancy — Strunk's Rule 12 table repeats examples already shown (e.g., `result` → `validationErrors`, `temp` → `unsavedDraft`). The explanations of Bloch's and Evans' principles are somewhat tutorial-like, though they stay reasonably tight.	2 / 3
Actionability	Highly actionable with concrete before/after examples across functions, variables, types, and booleans. The naming checklist is directly usable, the output format provides a copy-paste template, and both Review Mode and Design Mode give specific step-by-step diagnostic questions.	3 / 3
Workflow Clarity	Both Review Mode and Design Mode provide clear sequential steps. The output format with Must Rename / Consider Renaming / Design Concern tiers gives explicit structure for results. For a non-destructive analysis skill, this level of workflow clarity is excellent — no validation checkpoints are needed since naming review is non-destructive.	3 / 3
Progressive Disclosure	References `references/principles.md` for detailed rules, and has clear 'See Also' links to related skills. The main content stays at overview/actionable level without burying the reader in excessive detail, and cross-references are one level deep and well-signaled.	3 / 3
	Total	11 / 12 Passed

Description

89%

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

This is a strong description with excellent trigger terms and a clear 'Use when' clause that covers multiple realistic user scenarios. The main weakness is that the 'what' portion could be more specific about the concrete actions performed (e.g., suggesting alternatives, diagnosing design issues through naming struggles). Overall it would serve well for skill selection among many skills.

Suggestions

Expand the capability description with more concrete actions, e.g., 'Evaluate and improve names in code, suggest alternatives, flag misleading identifiers, and use naming difficulty as a signal for design problems.'

Dimension	Reasoning	Score
Specificity	The description names the domain (code naming) and a general action ('evaluate and improve names'), plus mentions 'naming as a design diagnostic', but doesn't list multiple concrete actions like 'suggest alternative names, flag misleading identifiers, analyze naming consistency across a codebase'.	2 / 3
Completeness	Clearly answers both 'what' (evaluate and improve names in code using naming as a design diagnostic) and 'when' (explicit 'Use when...' clause with multiple specific trigger scenarios).	3 / 3
Trigger Term Quality	Excellent coverage of natural trigger terms: 'name this', 'rename', 'review naming', 'what should I call', 'struggles to name something', 'vague or misleading names', and 'code review'. These are phrases users would naturally say.	3 / 3
Distinctiveness Conflict Risk	This occupies a clear niche — code naming specifically as a design diagnostic. The trigger terms are distinct and unlikely to conflict with general code review or refactoring skills, as they specifically target naming concerns.	3 / 3
	Total	11 / 12 Passed

Validation

90%

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 — 10 / 11 Passed

Validation for skill structure

Criteria	Description	Result
frontmatter_unknown_keys	Unknown frontmatter key(s) found; consider removing or moving to metadata	Warning

	Total	10 / 11 Passed

Repository: tslateman/duet
Commit: c3b1fc2

Reviewed: 3 months 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.