select-name

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

Quality

67%

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/select-name/SKILL.md

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-structured, lean overview that correctly defers code and verification detail to a single one-level-deep reference, but it carries minor redundancy (Fix restating Quick Reference), a vague Check step, and only implicit inline validation checkpoints.

Suggestions

Make the '## Check' step concrete (e.g. 'Inspect the accessibility tree for each <select>; confirm a name is present via <label for>, aria-label, or aria-labelledby') instead of restating the goal.

Surface a one-line inline verification checkpoint (e.g. 'Verify with axe/Lighthouse or the browser accessibility tree that each <select> exposes a name') before pointing to rule.md, so the workflow has an explicit validation step.

Drop or merge the meta '## Explain' section to remove filler and avoid the Fix/Quick Reference overlap.

Dimension	Reasoning	Score
Conciseness	The body is short and does not over-explain basics, but the '## Fix' section restates the Quick Reference bullet ('Use the <label> element with a matching for attribute') and the '## Explain' section is meta-instructional filler ('Explain how accessible names... provide the necessary context'). This matches score 2 'mostly efficient but... could be tightened' rather than score 3's 'every token earns its place'.	2 / 3
Actionability	Quick Reference and Fix give concrete, copy-paste-ready guidance ('<label> with a for matching the id', 'aria-label or aria-labelledby'), but the '## Check' section is vague ('Check that every <select>... has a valid accessible name') and no executable code example is inline (code is deferred to references/rule.md). This is above score 1 (which requires purely abstract direction) but below score 3's 'fully executable code/commands; copy-paste ready' because the inline guidance is incomplete.	2 / 3
Workflow Clarity	A light sequence exists (Check -> Fix -> Code Review) and the Code Review section mentions verifying the fix 'with browser accessibility tooling or assistive tech', but explicit validation checkpoints are not stated inline and the actual verification steps live in references/rule.md. This matches score 2 'steps listed but validation gaps; checkpoints missing or implicit' rather than score 3's 'explicit validation steps'.	2 / 3
Progressive Disclosure	The body is a concise overview and ends with a clearly signaled, one-level-deep reference ('see references/rule.md') for 'full implementation details, code examples, and framework-specific guidance'. The bundle file references/rule.md exists and holds the code/verification detail, matching score 3 'clear overview with well-signaled one-level-deep references'.	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 explicitly covers both what the skill does and when to use it, with several concrete review actions, but its trigger phrasing awkwardly embeds the rule title and leads with broad terms that overlap with sibling accessibility skills.

Suggestions

Rewrite the trigger to use natural user phrasing (e.g. 'Use when auditing a form or dropdown for accessibility, or when a <select> is missing a label/accessible name') instead of embedding the rule title.

Narrow the opening scope from 'interactive components, or design-system patterns' to select-element/form-label specifics to reduce overlap with other accessibility skills.

Dimension	Reasoning	Score
Specificity	Quotes 'Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output' list multiple concrete review actions, matching the score-3 anchor 'Lists multiple specific concrete actions'.	3 / 3
Completeness	It explicitly answers both: what ('Check native semantics... inspect keyboard behavior, focus flow, accessible names, and screen-reader output') and when ('Use when reviewing rendered HTML...'). The explicit 'Use when...' clause satisfies the guideline that allows completeness above 2, so it is not capped.	3 / 3
Trigger Term Quality	Relevant terms appear ('rendered HTML', 'select elements', 'accessible names', 'keyboard behavior', 'screen-reader output'), but the phrase 'related to Provide accessible names for select elements' awkwardly embeds the rule title rather than a natural user phrase, and 'design-system patterns' is broad. It is above score 1 (which requires no natural keywords) but below score 3's 'good coverage of natural terms users would say' because the title-embedded trigger is not something a user would naturally say.	2 / 3
Distinctiveness Conflict Risk	It is anchored to 'select elements' but the trigger 'reviewing rendered HTML, interactive components, or design-system patterns' is broad and would also fire for many other accessibility review skills. It is more specific than score 1 ('would conflict with many skills') but does not reach score 3's 'clear niche with distinct triggers; unlikely to conflict' because the opening trigger is generic.	2 / 3
	Total	10 / 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/select-name/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.