CtrlK
BlogDocsLog inGet started
Tessl Logo

list-structure

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

60

Quality

71%

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/list-structure/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

85%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, lean overview for a simple single-purpose rule: the core requirement, check, and fix are stated concretely, and detail is properly deferred to a real, clearly signaled one-level-deep reference file. Minor room for improvement lies in trimming the restated description in the Code Review section and inlining a minimal correct/incorrect markup example.

DimensionReasoningScore

Conciseness

The body is lean, with the Quick Reference bullets carrying the core rule, but two spots could be trimmed: the intro sentence re-explains a parent-child list concept Claude already knows, and the 'Code Review' section largely restates the frontmatter description.

4 / 5

Actionability

Concrete, executable instruction-style guidance ('only <li> elements' as direct children of ul/ol; 'Remove or move any non-li elements'), appropriate for an instruction-only skill. Not a 5 because the body has no inline correct/incorrect markup example and 'remove or move' leaves where to move the element unspecified — those details live only in references/rule.md.

4 / 5

Workflow Clarity

Simple single-purpose skill under 50 lines; the simple-skill exception applies — the single action (verify only li direct children) is unambiguous, and the Check → Fix → Explain → Code Review sequence is clean with verification of the fix explicitly noted.

5 / 5

Progressive Disclosure

A ~30-line well-organized overview with a single, clearly signaled, one-level-deep reference ('see references/rule.md'), which exists and contains the code examples and details the body defers; no nested or buried references.

5 / 5

Total

18

/

20

Passed

Description

58%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 has an explicit 'Use when...' trigger and several concrete inspection actions, but the actions are generic accessibility-review boilerplate misaligned with the actual list-structure task, and the phrase 'related to Use correct list structure' reads as an awkward injected rule name rather than a capability statement. Key natural trigger terms ('accessibility', 'lists', 'ul/ol') are absent, and the shared trigger vocabulary creates overlap risk with sibling accessibility skills.

Suggestions

State the domain-specific action directly, e.g. 'Verify that <ul>/<ol> lists contain only <li> direct children and fix or relocate invalid markup', instead of relying on generic accessibility-inspection phrases.

Add natural trigger keywords users would actually say: 'accessibility', 'a11y', 'screen reader', 'lists', 'list markup', 'ul/ol'.

Drop capabilities irrelevant to a static list-structure rule (keyboard behavior, focus flow) to reduce over-claiming and overlap with sibling interactive-component accessibility skills.

DimensionReasoningScore

Specificity

Only one stated action ('Check native semantics first') is tied to the list-structure domain; 'keyboard behavior, focus flow, accessible names' are generic accessibility-review actions that over-claim for a static-list rule, and the core task (verifying/fixing ul/ol children) is never named as an action.

3 / 5

Completeness

Both 'what' (check native semantics, inspect keyboard behavior, focus flow, accessible names, screen-reader output) and 'when' ('Use when reviewing rendered HTML, interactive components, or design-system patterns') are explicitly present. Not a 5 because the 'what' is muddled by the garbled phrase 'related to Use correct list structure' and never states what is actually done about list structure.

4 / 5

Trigger Term Quality

Includes some relevant keywords ('rendered HTML', 'screen-reader output', 'accessible names') but misses the most natural terms for this topic — 'accessibility', 'lists', 'list markup', 'ul/ol', 'a11y' — so common variations and synonyms are missing.

3 / 5

Distinctiveness Conflict Risk

'related to Use correct list structure' names a specific niche, but the trigger terms (rendered HTML, interactive components, design-system patterns, keyboard behavior, focus flow, accessible names) are shared across all sibling accessibility-rule skills, so overlap with similar skills remains likely.

3 / 5

Total

13

/

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.