CtrlK
BlogDocsLog inGet started
Tessl Logo

specificity-management

Use when reviewing stylesheets, component styles, and responsive behavior related to Keep CSS specificity low and flat. Check the rendered layout across breakpoints and interaction states before proposing a fix.

51

Quality

56%

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/specificity-management/SKILL.md
SKILL.md
Quality
Evals
Security

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 body is well-structured with a clear overview that defers details to a real, one-level-deep reference, exemplifying good progressive disclosure. Its weaknesses are a mildly redundant conceptual opener, an absence of executable code examples in SKILL.md itself, and no in-body validation checkpoint for the review workflow.

Suggestions

Trim or cut the opening escalation paragraph — Claude already understands CSS specificity, so the body can start with the actionable Quick Reference.

Surface at least one small executable example (e.g. a before/after selector pair or a :where() snippet) directly in SKILL.md rather than only in the reference, so the body is actionable on its own.

Add a brief verification checkpoint in the body (e.g. 'After changes, confirm computed styles in DevTools and re-check the affected breakpoints') so the Check→Fix loop has an explicit validation step without requiring the reference.

DimensionReasoningScore

Conciseness

The body is mostly lean with actionable bullets and terse Check/Fix sections, but the opening paragraph re-explains a basic concept Claude already knows ('High specificity creates an escalation problem — once you use an ID selector, you need another ID to override it') and could be trimmed.

2 / 3

Actionability

The Quick Reference bullets and Check/Fix sections give concrete, specific guidance ('Avoid nesting selectors more than 3 levels deep', 'Use :where() to apply styles with zero specificity'), but the body itself contains no executable code examples — those are deferred to references/rule.md — so guidance is actionable but incomplete in SKILL.md.

2 / 3

Workflow Clarity

The Check → Fix → Explain → Code Review sections provide a recognizable sequence, but the body has no explicit validation/verification checkpoint (the Verification steps live only in the reference), and the framing is multiple modes rather than one unambiguous action.

2 / 3

Progressive Disclosure

SKILL.md acts as a concise overview and clearly signals a single one-level-deep reference — 'For full implementation details, code examples, and framework-specific guidance, see references/rule.md' — and that file exists, giving clean navigation without nested references.

3 / 3

Total

9

/

12

Passed

Description

55%

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 has a clear 'Use when' trigger and good natural terminology, but its capability statement is muddled by an embedded rule title and an imperative instruction that also violates the third-person voice convention. Tightening it into a third-person statement of what the skill does would lift both specificity and completeness.

Suggestions

Rewrite in third person as a capability statement, e.g. 'Reviews CSS selectors for high specificity (IDs, deep nesting, !important) and proposes flatter class-based alternatives. Use when reviewing stylesheets, component styles, or responsive behavior for CSS specificity issues.'

Remove the imperative 'Check the rendered layout...' instruction from the description — it reads as a workflow step, not a capability, and triggers the second-person voice penalty.

Drop the embedded rule title ('related to Keep CSS specificity low and flat') so the 'what' reads as a concrete action rather than a reference to the rule name.

DimensionReasoningScore

Specificity

The description names the domain and some actions ('reviewing stylesheets, component styles, and responsive behavior', 'Check the rendered layout across breakpoints and interaction states'), but the second sentence is imperative/second-person ('Check the rendered layout...'), which per the voice guideline reduces specificity by one from a base of 2.

1 / 3

Completeness

The 'when' is explicit ('Use when reviewing stylesheets, component styles, and responsive behavior related to...'), but the 'what' is tangled: the capability (flagging specificity violations, proposing flat selectors) is implied via an instruction ('Check the rendered layout...before proposing a fix') and an awkwardly embedded rule title rather than stated cleanly.

2 / 3

Trigger Term Quality

It uses natural terms a frontend user would actually say — 'stylesheets', 'component styles', 'responsive behavior', 'breakpoints', 'interaction states', and 'CSS specificity' — giving good coverage rather than jargon.

3 / 3

Distinctiveness Conflict Risk

The CSS-specificity niche is fairly specific, but foregrounding 'reviewing stylesheets, component styles, and responsive behavior' broadens the trigger and could overlap with general CSS or responsive-review skills.

2 / 3

Total

8

/

12

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.