naming-conventions

Use when reviewing stylesheets, component styles, and responsive behavior related to Use consistent CSS naming conventions. Check the rendered layout across breakpoints and interaction states before proposing a fix.

Quality

62%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/naming-conventions/SKILL.md

Quality

Content

57%

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

The skill uses clean progressive disclosure — a lean overview pointing to a real references/rule.md with the code examples and verification steps — but the body itself relies on concept explanation Claude already knows and vague audit questions, and lacks an explicit sequenced workflow with validation checkpoints. Actionability is decent where concrete BEM rules are given but uneven across sections.

Suggestions

Remove or compress the intro paragraph and 'Explain' section that restate BEM concepts Claude already knows.

Number the Check -> Fix -> Verify -> Code Review steps and surface at least one verification checkpoint (e.g., 'Confirm computed styles match the intended fix in DevTools') in the body.

Make the 'Check' section actionable with concrete criteria or a short example selector to audit, rather than open-ended questions.

Dimension	Reasoning	Score
Conciseness	The body is fairly lean, but the opening paragraph ('Without a naming convention, class names become a guessing game...') and the 'Explain' section restate concepts Claude already knows about BEM and why naming matters, so it could be tightened rather than earning the lean level-3 anchor.	2 / 3
Actionability	Concrete specific guidance is present ('Rename classes to follow BEM methodology: Block, Block__Element, Block--Modifier pattern', 'Use kebab-case... Namespace utility classes and JS hooks separately'), but the 'Check' and 'Explain' sections are vague audit questions with no worked example in the body, leaving the guidance incomplete.	2 / 3
Workflow Clarity	The Check -> Fix -> Explain -> Code Review sections imply a loose sequence, but steps are unnumbered and the body omits any validation/verification checkpoint (the verification steps live only in references/rule.md), which caps a reviewing/fixing workflow at 2.	2 / 3
Progressive Disclosure	The body is a concise overview that clearly signals a single one-level-deep reference ('see references/rule.md' for full implementation details, code examples, and framework-specific guidance), and that file exists with the detailed code, mistakes, and verification content appropriately split out.	3 / 3
	Total	9 / 12 Passed

Description

67%

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 explicitly covers both what the skill does and when to use it, with a clear 'Use when' trigger, but its actions are abstract and the broad stylesheet-review framing creates overlap risk with sibling CSS skills. Trigger terms are relevant but miss common variations and awkwardly embed the rule title.

Suggestions

Replace abstract review verbs with concrete capabilities (e.g., 'Audit class names for BEM compliance, rename ambiguous selectors, namespace utility and JS-hook classes').

Add natural trigger variations users would actually say, such as 'class names', 'BEM', or 'CSS classes', and drop the awkward embedded rule title.

Narrow the 'when' clause to naming-specific triggers so it does not collide with other stylesheet/responsive-review skills.

Dimension	Reasoning	Score
Specificity	The description names a domain ('stylesheets, component styles, and responsive behavior') and some actions ('reviewing', 'Check the rendered layout', 'proposing a fix'), but the actions are abstract review verbs rather than a list of multiple concrete capabilities, so it does not reach the level-3 anchor.	2 / 3
Completeness	An explicit 'Use when...' clause supplies the trigger (when), and the what is stated concretely ('Check the rendered layout across breakpoints and interaction states before proposing a fix'), so both what and when are explicitly answered.	3 / 3
Trigger Term Quality	It includes relevant natural terms ('stylesheets', 'CSS naming conventions', 'breakpoints', 'interaction states'), but the awkward embedded rule title ('related to Use consistent CSS naming conventions') and absence of common variations like 'class names', 'BEM', or 'CSS classes' leave it short of full coverage.	2 / 3
Distinctiveness Conflict Risk	It is scoped to CSS naming conventions (a distinct niche), but the broad trigger 'reviewing stylesheets, component styles, and responsive behavior' would overlap with many similar CSS/frontend review skills, so it could still trigger for the wrong skill.	2 / 3
	Total	9 / 12 Passed

Validation

93%

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 — 15 / 16 Passed

Validation for skill structure

Criteria	Description	Result
metadata_version	'metadata.version' is missing	Warning

	Total	15 / 16 Passed

Repository: thedaviddias/Front-End-Checklist
Path: skills/naming-conventions/SKILL.md
Commit: 48405aa

Reviewed: about 8 hours 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.