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.

55

Quality

62%

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

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 a well-organized overview that correctly offloads detail to a one-level reference, but its guidance describes rather than instructs (no executable method) and carries redundant and off-topic boilerplate that dilutes conciseness and actionability.

Suggestions

Consolidate the repeated 'only <li> as direct children' rule from Quick Reference, Check, and Fix into a single stated rule plus concrete remediation steps.

Add an executable detection method, e.g. a CSS selector or XPath like //ul/*[not(self::li)] | //ol/*[not(self::li)] or a DevTools snippet, instead of only describing what to check.

Trim the Code Review boilerplate (roles, labels, focus behavior, keyboard interactions) to list-structure-relevant verification only, such as screen-reader item-count/position announcements.

DimensionReasoningScore

Conciseness

The body is mostly lean, but Quick Reference, Check, and Fix repeat the same 'only <li> as direct children' point, and the Code Review section carries generic boilerplate (roles, labels, focus behavior, keyboard interactions) irrelevant to list structure.

2 / 3

Actionability

It names concrete elements to inspect (<ul>, <ol>, <li>, <div>, <p>) but gives no executable method (no CSS selector, XPath, or DOM-inspection command), and defers all code examples to the reference file.

2 / 3

Workflow Clarity

Check, Fix, Explain, and Code Review provide a recognizable sequence and a verification hint ('note how to verify the fix with browser accessibility tooling'), but there is no explicit validate-then-retry loop tying the steps together.

2 / 3

Progressive Disclosure

The SKILL.md is a concise overview with well-signaled, one-level-deep navigation to references/rule.md (which exists) for full implementation details, code examples, and framework-specific guidance.

3 / 3

Total

9

/

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 answers both what and when with an explicit trigger, but its action language and trigger phrasing are generic accessibility-review boilerplate not tailored to list structure, weakening specificity, trigger quality, and distinctiveness.

Suggestions

Replace the generic 'inspect keyboard behavior, focus flow, accessible names' actions with list-structure-specific checks (e.g., 'find <ul>/<ol> with non-<li> direct children, verify nested lists are wrapped in an <li>').

Add natural trigger terms users actually say, such as 'list accessibility', 'screen reader list announcements', or 'invalid list markup', instead of repeating the rule title.

Differentiate from sibling accessibility skills by foregrounding the parent-child list-relationship problem rather than the shared native-semantics/keyboard review boilerplate.

DimensionReasoningScore

Specificity

It names concrete review actions ('Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output'), but these are generic accessibility-review steps rather than actions specific to list structure, so it is not comprehensive for this skill.

2 / 3

Completeness

It explicitly answers both what (check native semantics, inspect keyboard behavior, focus flow, accessible names, screen-reader output) and when via an explicit 'Use when reviewing rendered HTML...' trigger clause.

3 / 3

Trigger Term Quality

It includes some relevant phrases ('rendered HTML', 'interactive components', 'design-system patterns') but repeats the rule title 'Use correct list structure' rather than offering natural variations a user would say, missing common terms like 'list accessibility' or 'screen reader lists'.

2 / 3

Distinctiveness Conflict Risk

The body is generic boilerplate shared across accessibility rules (same native-semantics/keyboard/focus/screen-reader phrasing); only 'Use correct list structure' distinguishes it, so it could overlap with sibling a11y skills.

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.