decorative-elements

Use when reviewing rendered HTML, interactive components, or design-system patterns related to Hide decorative elements from assistive technology. Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output where relevant. If an image is clearly decorative, default to no finding unless the snippet shows an actual issue such as broken semantics, focusability, or visible layout instability.

Quality

82%

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

Quality

Content

72%

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

A well-organized review skill with concrete attribute-level guidance and good progressive disclosure via a verified one-level reference. Weaker on conciseness (redundant restating of the same rules across sections) and workflow clarity (parallel template sections instead of a sequenced, checkpointed review flow).

Suggestions

Consolidate the redundant rule lists: Quick Reference, Check, and Fix all restate the same alt=''/aria-hidden='true'/CSS-background-image/role='presentation' guidance — merge into one canonical list and let Check/Fix reference it, cutting tokens (conciseness).

Replace the parallel Check/Fix/Explain/Code Review sections with an explicit sequenced review workflow with a verification checkpoint, e.g. 1) inspect markup for decorative img/SVG/icon-font elements, 2) confirm alt='' / aria-hidden='true' / CSS background usage, 3) verify with a screen reader or axe DevTools before reporting (workflow_clarity).

Drop or shorten the 'Explain' section, which restates the intro paragraph about screen readers announcing every image — keep a single concise rationale to reduce further redundancy (conciseness).

Dimension	Reasoning	Score
Conciseness	Mostly efficient and free of basic-concept padding, but Quick Reference, Check, and Fix all restate the same alt=''/aria-hidden/CSS-background rules in slightly different framings, so it could be tightened rather than earning the 'every token earns its place' level.	2 / 3
Actionability	Gives concrete, directly applicable guidance with exact attribute values ('alt=''', 'aria-hidden='true', 'role='presentation', CSS background-image) plus a copy-paste example ('<img src="/divider.svg" alt="" aria-hidden="true">'); for an instruction-only review skill this is specific and actionable rather than vague or pseudocode.	3 / 3
Workflow Clarity	Checks and a verification mention ('note how to verify the fix with browser accessibility tooling or assistive tech') are present, but the body organizes guidance as parallel Check/Fix/Explain/Code Review template sections rather than a sequenced workflow with explicit validation checkpoints, fitting the 'steps listed but checkpoints missing or implicit' anchor.	2 / 3
Progressive Disclosure	The body is a concise, well-sectioned overview that signals a single one-level-deep reference ('For full implementation details, code examples, and framework-specific guidance, see references/rule.md'), and that reference file exists with the detailed examples, matching clear overview plus well-signaled one-level references.	3 / 3
	Total	10 / 12 Passed

Description

92%

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong description with an explicit 'Use when' trigger, concrete multi-step actions, and good natural keyword coverage. Its only weakness is distinctiveness, since the broadened accessibility-inspection scope could overlap with other accessibility skills.

Dimension	Reasoning	Score
Specificity	Lists multiple concrete actions — 'Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output' and 'default to no finding unless the snippet shows an actual issue such as broken semantics, focusability, or visible layout instability' — matching the 'lists multiple specific concrete actions' anchor rather than the domain-plus-some-actions level below.	3 / 3
Completeness	Answers both what ('Check native semantics... inspect keyboard behavior, focus flow, accessible names, and screen-reader output') and when with an explicit 'Use when reviewing rendered HTML, interactive components, or design-system patterns...' trigger, so it is not capped at 2.	3 / 3
Trigger Term Quality	Covers natural terms a reviewer would say — 'rendered HTML', 'interactive components', 'design-system patterns', 'decorative elements', 'assistive technology', 'keyboard behavior', 'focus flow', 'accessible names', 'screen-reader' — giving good coverage rather than just some relevant keywords.	3 / 3
Distinctiveness Conflict Risk	The 'Hide decorative elements from assistive technology' niche is distinct, but the broadened inspection scope ('keyboard behavior, focus flow, accessible names, and screen-reader output') overlaps with general accessibility-review skills, so it could still conflict with similar skills rather than occupying a clearly isolated niche.	2 / 3
	Total	11 / 12 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/decorative-elements/SKILL.md
Commit: 48405aa

Reviewed: about 8 hours 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.