CtrlK
BlogDocsLog inGet started
Tessl Logo

heading-order

Use when reviewing rendered HTML, interactive components, or design-system patterns related to Maintain logical heading order. Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output where relevant.

58

Quality

67%

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/heading-order/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 good progressive disclosure to a real reference file, but it spends tokens explaining concepts Claude already knows and keeps verification guidance implicit. Inlining a concrete check command and trimming redundant rationale would lift the weaker dimensions.

Suggestions

Remove or condense the intro and "Explain" rationale about why heading order matters, since Claude already knows this.

Add an explicit verification checkpoint (e.g. "Run axe/Lighthouse or inspect the accessibility tree and confirm no skipped levels remain") instead of a vague note to verify.

Inline one concrete check snippet or selector for skipped headings so the body is actionable without requiring the reference.

DimensionReasoningScore

Conciseness

The intro and "Explain" sections restate why heading order matters — a concept Claude already knows — and "Quick Reference" overlaps with "Check", so the body is mostly efficient but carries unnecessary explanation.

2 / 3

Actionability

Concrete inline examples appear ("change an <h3> to an <h2> if it follows an <h1>"), but the executable HTML examples live in references/rule.md rather than the body, leaving the guidance high-level rather than copy-paste ready.

2 / 3

Workflow Clarity

A clear Check→Fix→Explain→Code Review sequence is present, but verification is only vaguely referenced ("note how to verify the fix with browser accessibility tooling") rather than given as explicit checkpoints.

2 / 3

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 to references/rule.md, which exists, matching the clear-overview anchor.

3 / 3

Total

9

/

12

Passed

Description

77%

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 answers both what and when with concrete inspection actions, but its trigger terms are incomplete and the broad review framing risks overlap with other accessibility skills. Tightening the triggers to natural heading-specific phrasing would raise distinctiveness and trigger quality.

Suggestions

Add natural trigger variations users would actually say, e.g. "headings", "h1/h2", "skipped heading levels", or "heading hierarchy".

Narrow the trigger scope from generic "rendered HTML, interactive components, design-system patterns" to heading-structure-specific contexts to reduce conflict with sibling accessibility skills.

Reword the awkward "related to Maintain logical heading order" embedding into a cleaner statement of the skill's purpose.

DimensionReasoningScore

Specificity

Lists multiple concrete inspection actions — "Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output" — matching the multiple-specific-actions anchor rather than the single-action score-2 anchor.

3 / 3

Completeness

An explicit "Use when reviewing..." clause answers when, and the subsequent check/inspect actions answer what, satisfying both halves with explicit triggers rather than only implying one.

3 / 3

Trigger Term Quality

Includes relevant terms ("heading order", "rendered HTML", "interactive components") but omits common variations a user would naturally say ("headings", "h1/h2", "skipped headings", "heading hierarchy"), so coverage is partial rather than comprehensive.

2 / 3

Distinctiveness Conflict Risk

The broad triggers ("rendered HTML, interactive components, or design-system patterns") would overlap with sibling accessibility skills; only the embedded "heading order" phrase narrows it, leaving it somewhat specific but still prone to conflict.

2 / 3

Total

10

/

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.