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.
89
87%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Quality
Discovery
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 |
Implementation
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 |
Validation
90%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
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.