CtrlK
BlogDocsLog inGet started
Tessl Logo

html5-semantic-elements

Use when reviewing templates, rendered HTML, or shared components related to Use semantic HTML elements. Validate the final browser-facing markup, not just the source framework abstraction.

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/html5-semantic-elements/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

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

The body is a well-organized overview with exemplary progressive disclosure — a concise Quick Reference plus one clearly signaled reference file carrying the detailed examples. The weaknesses are redundant concept explanation (intro and 'Explain' sections) that Claude doesn't need, and Check/Fix guidance that stays at the level of direction rather than concrete, executable instructions.

Suggestions

Cut the intro paragraph and the 'Explain' section — Claude already knows why semantic HTML matters for screen readers and SEO; keep only the non-obvious Quick Reference rules like 'Only one <main> per page'.

Add a compact before/after snippet to the 'Fix' section (a div-soup block next to its semantic rewrite) so the guidance is concrete rather than directional.

Make 'Check' operational: specify what to inspect (rendered/DOM output vs. framework source) and what counts as a violation (e.g., generic containers wrapping nav/main/article content), rather than 'Review this HTML structure'.

DimensionReasoningScore

Conciseness

Mostly efficient, but the intro ('Screen readers use semantic elements to navigate pages... Search engines also use semantics to understand content hierarchy') and the entire 'Explain' section restate why semantic HTML matters — background knowledge Claude already has. Not score 4, since these sections are clearly trimmable rather than minor instances of over-explanation.

3 / 5

Actionability

The Quick Reference gives a concrete element mapping ('<article> for self-contained content, <section> for grouped content'), but 'Review this HTML structure to ensure...' and 'Replace generic div elements with semantic HTML5 elements' are direction without a concrete before/after example or inspection method. Not score 2 — the element mapping is genuinely concrete guidance — but key executable details are missing from the body.

3 / 5

Workflow Clarity

For this simple single-purpose skill, the Check → Fix sequence is clear and the 'Flag exact elements, attributes, and routes' instruction gives an unambiguous single action. Not score 5 because the Check, Explain, and Code Review sections partially duplicate one another, leaving the intended workflow (inspect rendered markup → flag → fix) slightly ambiguous about which section governs.

4 / 5

Progressive Disclosure

A lean, well-sectioned overview body with a single clearly signaled one-level-deep reference ('For full implementation details, code examples, and framework-specific guidance, see references/rule.md' — verified to exist and contain the full example). Content is appropriately split between the overview and the reference; easy navigation.

5 / 5

Total

15

/

20

Passed

Description

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

A solid description with an explicit 'Use when' trigger and a genuinely useful distinguishing angle (validate the final browser-facing markup, not the framework abstraction). Its main weaknesses are the garbled 'related to Use semantic HTML elements' phrase, which blurs the core action, and missing natural trigger synonyms like 'accessibility' and 'screen readers'.

Suggestions

Rewrite the phrase 'related to Use semantic HTML elements' into an explicit capability statement, e.g. 'Flag non-semantic div-based markup and suggest semantic replacements' — this would lift specificity and completeness.

Add natural trigger terms users actually say, such as 'accessibility', 'screen readers', 'SEO', or 'div soup', to improve trigger_term_quality and distinctiveness.

State the deliverable in the 'what' portion (e.g. 'reports exact elements, attributes, and routes that violate the rule') so the description reads as a concrete action rather than a review scope.

DimensionReasoningScore

Specificity

Names the domain ('semantic HTML elements') and 1-2 concrete actions ('reviewing templates, rendered HTML, or shared components', 'Validate the final browser-facing markup'), but coverage is not comprehensive — it never states what the skill does with violations (flag them, fix them). Not score 4, which requires several specific actions listed; not score 2, since more than a bare domain name is given.

3 / 5

Completeness

Both parts are present: an explicit 'Use when reviewing templates, rendered HTML, or shared components...' trigger and a 'what' ('Validate the final browser-facing markup, not just the source framework abstraction'). Not score 5 because the 'what' is muddied by the awkward 'related to Use semantic HTML elements' phrasing, leaving the core action (flag semantic-HTML violations) implicit rather than concretely stated.

4 / 5

Trigger Term Quality

Good natural keyword coverage: 'templates', 'rendered HTML', 'shared components', 'browser-facing markup', 'semantic HTML elements'. A few natural terms users would say are missing, e.g. 'accessibility', 'screen readers', 'SEO', 'divs', 'markup vs. source'. Not score 5, which requires comprehensive synonyms/extensions coverage.

4 / 5

Distinctiveness Conflict Risk

Reviewing rendered markup for semantic HTML elements is a clear niche with distinct triggers ('rendered HTML', 'browser-facing markup', 'source framework abstraction'). Minor overlap risk with sibling frontend/accessibility checklist skills keeps it below score 5.

4 / 5

Total

15

/

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.

Validation — 15 / 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.