CtrlK
BlogDocsLog inGet started
Tessl Logo

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.

57

Quality

66%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/naming-conventions/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

71%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 concise, well-structured review skill that appropriately pushes detail to a one-level-deep reference file and lays out a clear Check/Fix/Explain workflow. Its main weakness is actionability: the body's Fix and Check sections are thin one-liners with no inline examples, relying entirely on the reference for concrete guidance.

Suggestions

Add one short inline BEM rename example in the Fix section (e.g. '.btn.active → .button--active') so the body is actionable without forcing a jump to the reference.

Tighten the intro analogy or merge it into Quick Reference to remove the only lightly-padded passage.

Make the Check section's audit prompts more concrete by listing the specific ambiguity signals to look for (e.g. shared class names across components, unscoped state classes).

DimensionReasoningScore

Conciseness

The body is lean (~30 lines), does not explain basic CSS concepts, and every section earns its place; the brief intro analogy ('does .active mean the nav item is active...') is the only mildly explanatory padding.

4 / 5

Actionability

Guidance names the BEM pattern ('Block, Block__Element, Block--Modifier') and poses concrete audit questions, but the Check/Fix sections are one-liners with no inline examples — concrete details are deferred entirely to references/rule.md, leaving the body itself incomplete.

3 / 5

Workflow Clarity

The Check → Fix → Explain → Code Review sequence gives a coherent review workflow with an unambiguous single purpose; no validation checkpoints are needed since this is a non-destructive review task, fitting the simple-skill exception.

4 / 5

Progressive Disclosure

The body is a well-organized overview (Quick Reference, Check, Fix, Explain, Code Review) with a single clearly-signaled one-level-deep reference ('see references/rule.md') that resolves to a real file, matching the under-50-lines simple-skill guidance.

5 / 5

Total

16

/

20

Passed

Description

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

The description includes an explicit 'Use when...' trigger and several concrete review actions with natural frontend terms, but a template-substitution glitch embeds the rule title mid-sentence ('related to Use consistent CSS naming conventions'), degrading clarity of the core capability. It is functional but would benefit from a rewrite that states the action in clean third person.

Suggestions

Rewrite the description in clean third person without the embedded rule title, e.g. 'Reviews CSS class naming conventions (BEM and similar) in stylesheets and component styles. Use when auditing CSS naming consistency or debugging style conflicts across breakpoints and interaction states.'

Add common synonyms users would actually say — 'BEM', 'class names', 'CSS classes', 'style conflicts' — to strengthen trigger-term coverage.

Lead with the 'what' before the 'when' so the skill's purpose is unambiguous before the trigger clause.

DimensionReasoningScore

Specificity

Names the domain (stylesheets, component styles, responsive behavior, breakpoints, interaction states) and a few concrete review actions ('Check the rendered layout across breakpoints... before proposing a fix'), but the actions are generic review verbs and the embedded rule title muddies clarity.

3 / 5

Completeness

Both a 'what' (review CSS naming conventions) and a 'when' ('Use when reviewing stylesheets...') are present, but the 'what' is muddled by the garbled phrase 'related to Use consistent CSS naming conventions', leaving the core capability less than clearly stated.

3 / 5

Trigger Term Quality

Includes natural frontend terms a user would say ('reviewing stylesheets', 'component styles', 'responsive behavior', 'breakpoints', 'interaction states'), though synonyms like 'BEM', 'class names', or 'CSS classes' are missing.

4 / 5

Distinctiveness Conflict Risk

The CSS naming-convention niche with breakpoint/interaction-state triggers is mostly distinct from other skills, with only minor overlap risk against broader CSS-review skills.

4 / 5

Total

14

/

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_version

'metadata.version' is missing

Warning

Total

15

/

16

Passed

Repository
thedaviddias/Front-End-Checklist
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.