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.

60

Quality

70%

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

72%

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

The SKILL.md body is a well-structured, lean overview that correctly defers detail to a real, one-level-deep reference file. Its main weaknesses are actionability and workflow clarity: the Check/Fix guidance is somewhat abstract and lacks an inline verification checkpoint, even though the reference file contains a thorough Verification section.

Suggestions

Tighten the Check and Fix sections into concrete, criteria-based steps (e.g. "List each <div> used for page structure and state the semantic element it should become") rather than descriptive instructions.

Add a brief inline verification checkpoint in the body (e.g. "Confirm exactly one <main> per page and that no <div> carries a landmark role") so the workflow has an explicit validation step before deferring to references/rule.md.

Pull one small concrete anti-pattern/example pair into the body so the review guidance is immediately actionable without needing to open the reference.

DimensionReasoningScore

Conciseness

The body is lean: short Quick Reference bullets and brief Check/Fix/Explain/Code Review sections with no padding; the single opening sentence frames the purpose without explaining concepts Claude already knows at length, so every token earns its place.

3 / 3

Actionability

The Quick Reference gives concrete element mappings ("Use <article> for self-contained content", "Only one <main> per page"), but the Check and Fix sections are descriptive ("Review this HTML structure to ensure it uses appropriate semantic elements...", "Replace generic div elements with semantic HTML5 elements") rather than providing concrete, copy-ready review procedures or criteria.

2 / 3

Workflow Clarity

The Check/Fix/Explain/Code Review sections imply a loose sequence, but no explicit validation or verification checkpoint is present in the body — verification is deferred to the reference file rather than stated inline, leaving the workflow sequence without an explicit checkpoint.

2 / 3

Progressive Disclosure

The body is a concise overview that 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 and holds the detailed material, matching the score-3 anchor for well-signaled one-level references.

3 / 3

Total

10

/

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 has an explicit Use-when trigger and answers both what and when, but is constructed awkwardly — the literal rule title "Use semantic HTML elements" is embedded mid-sentence ("related to Use semantic HTML elements"), producing ungrammatical phrasing. Trigger coverage and distinctiveness are adequate rather than strong, and the specificity of concrete actions is limited.

Suggestions

Reword to remove the embedded rule title so the sentence is grammatical, e.g. "Validate that templates and rendered HTML use semantic HTML5 elements (header, main, article, section, aside, footer) rather than generic divs."

Expand trigger terms to include natural user phrasings such as "HTML structure", "accessibility landmarks", "div soup", and "markup".

Add a second concrete action (e.g. "Flag exact elements and routes where rendered markup violates semantic structure") to lift specificity toward score 3.

DimensionReasoningScore

Specificity

The description names the domain ("semantic HTML elements", "templates, rendered HTML, or shared components") and a concrete action ("Validate the final browser-facing markup"), but does not enumerate multiple distinct concrete actions as the score-3 anchor requires.

2 / 3

Completeness

It explicitly answers both what ("Validate the final browser-facing markup, not just the source framework abstraction") and when (an explicit "Use when reviewing templates, rendered HTML, or shared components..." trigger clause), satisfying the score-3 anchor for both what and when.

3 / 3

Trigger Term Quality

Natural terms a user would say are present ("templates", "rendered HTML", "shared components", "semantic HTML elements"), but common variations a user might voice (e.g. "HTML structure", "accessibility", "divs", "markup") are missing, so it is not full score-3 coverage.

2 / 3

Distinctiveness Conflict Risk

The "final browser-facing markup" / "semantic HTML elements" framing carves out a niche, but the trigger still overlaps with sibling HTML-review skills that would also fire on "reviewing templates, rendered HTML, or shared components", so it is not cleanly distinct.

2 / 3

Total

9

/

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.