definition-list

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

Quality

64%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/definition-list/SKILL.md

Quality

Content

65%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-structured overview that defers detail to a real, clearly signaled reference file, but its inline Fix guidance is vague and the workflow lacks explicit validation checkpoints.

Suggestions

Make the Fix step concrete with a short inline good/bad HTML snippet instead of 'wrap them appropriately to maintain semantic integrity'.

Add an explicit re-verification checkpoint after the Fix step (e.g., 're-run the accessibility tree / axe check to confirm only dt, dd, or valid wrappers remain').

Trim the templated 'Code Review' and 'Explain' paragraphs to reduce boilerplate that repeats across sibling rule skills.

Dimension	Reasoning	Score
Conciseness	The body is mostly lean with a short intro, Quick Reference bullets, and brief Check/Fix sections, but the templated 'Code Review' and 'Explain' prose ('Review the rendered markup and interactive states that affect Use correct definition list structure. Flag exact elements, roles, labels, focus behavior...') could be trimmed.	4 / 5
Actionability	Concrete checklist guidance exists ('Ensure <dl> contains only <dt>, <dd>, or <script>/<template> tags'), but the Fix step is vague ('wrap them appropriately to maintain semantic integrity') and no executable code examples appear in the body — they are deferred to references/rule.md.	3 / 5
Workflow Clarity	A loose Check→Fix sequence is present, but explicit validation checkpoints are missing or implicit in the body, and the actual verification procedure lives in references/rule.md rather than being sequenced inline.	3 / 5
Progressive Disclosure	The body is a clear overview that explicitly signals a one-level-deep reference ('For full implementation details, code examples, and framework-specific guidance, see references/rule.md'), and that referenced file exists, giving clean navigation.	5 / 5
	Total	15 / 20 Passed

Description

63%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 covers both what the skill does and when to use it with several concrete actions, but its trigger phrasing is templated and generic across the accessibility category, hurting naturalness and distinctiveness.

Suggestions

Rewrite the templated 'related to Use correct definition list structure' phrase into a natural trigger such as 'Use when reviewing pages that use <dl>/<dt>/<dd> description lists or when users mention definition-list markup.'

Add concrete element-level terms (dl, dt, dd, description list) so the trigger matches what users actually say.

Narrow the 'when' clause to definition-list-specific contexts to reduce overlap with other accessibility rule skills.

Dimension	Reasoning	Score
Specificity	Lists several concrete review actions ('Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output'), though they are generic accessibility steps rather than definition-list-specific.	4 / 5
Completeness	Both a 'what' (check semantics, inspect keyboard/focus/accessible names/screen-reader output) and an explicit 'when' ('Use when reviewing rendered HTML, interactive components, or design-system patterns...') are present, but the 'when' clause is awkward and could be more specific.	4 / 5
Trigger Term Quality	Relevant keywords appear ('rendered HTML', 'interactive components', 'design-system patterns', 'definition list') but common synonyms and element names users would say (dl, dt, dd, description list) are missing, and the embedded phrase 'related to Use correct definition list structure' reads as templated rather than natural.	3 / 5
Distinctiveness Conflict Risk	The 'definition list structure' scope narrows the niche, but the broad 'reviewing rendered HTML, interactive components, or design-system patterns' trigger would plausibly fire for sibling accessibility rule skills, creating overlap risk.	3 / 5
	Total	14 / 20 Passed

Validation

93%

Warnings & errors only

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

Criteria	Description	Result
metadata_version	'metadata.version' is missing	Warning

	Total	15 / 16 Passed

Repository: thedaviddias/Front-End-Checklist
Path: skills/definition-list/SKILL.md
Commit: 30756a7

Reviewed: 23 days ago

Table of Contents

Discovery Implementation Validation

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.