aria-command-name

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

Quality

59%

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

Quality

Content

60%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 lean, well-structured overview that correctly offloads detail to references/rule.md. Its weakness is actionability: the SKILL.md itself contains no executable markup examples or selectors, and the review workflow lacks explicit validation checkpoints despite the rule being verification-oriented.

Suggestions

Add one small inline code example (a before/after button markup or a selector like 'button:not([aria-label]):empty') so the body is actionable without forcing a file load.

Add an explicit validation step to the Code Review section (e.g. 'Verify the fix with the browser accessibility tree or axe') to create a check-then-confirm loop.

Briefly annotate what references/rule.md contains (e.g. 'code examples, exceptions, and verification steps') so the reader knows the value of loading it.

Dimension	Reasoning	Score
Conciseness	The body is short and assumes Claude's competence, with only minor over-explanation ('Ensures users know the purpose of the interactive element', 'Explain how accessible names...') that restates the rule rather than adding new knowledge.	4 / 5
Actionability	It gives high-level remediation hints ('Add an accessible name using inner text, aria-label, or aria-labelledby') and points to references/rule.md for examples, but the SKILL.md body itself contains no executable code or selector examples; the concrete HTML examples live only in the reference file.	3 / 5
Workflow Clarity	The Check / Fix / Explain / Code Review sections give a rough review sequence, but there are no validation checkpoints or verify-the-fix loops in the body, and the review operation lacks explicit feedback steps despite involving verification.	3 / 5
Progressive Disclosure	Structure is clean with a well-signaled one-level-deep pointer to references/rule.md (which exists) and a rule-page link; content is appropriately split, with only minor gaps (the body duplicates the rule title and the reference is named but not described by topic).	4 / 5
	Total	14 / 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 is clearly scoped to a distinct accessibility niche with an explicit 'Use when' trigger and several concrete reviewing actions. It loses points for trigger-term naturalness (users rarely say 'ARIA command elements') and for action specificity leaning toward review rather than concrete remediation.

Suggestions

Add natural user phrasings to the 'Use when' clause, e.g. 'Use when a button, link, or menu item has no label or an unclear name' to improve trigger-term quality.

Name the concrete remediation actions (add inner text, aria-label, or aria-labelledby) in the description so it covers both detecting and fixing the issue.

Drop the redundant restatement of the rule title inside the description to tighten the prose and avoid padding.

Dimension	Reasoning	Score
Specificity	The description names the domain (accessible names for ARIA command elements) and concrete reviewing actions ('Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output'), giving several specific actions but no implementation actions like adding labels.	3 / 5
Completeness	It explicitly answers both what ('Provide accessible names for ARIA command elements') and when (the 'Use when reviewing rendered HTML...' clause), but the 'when' is generic and lacks concrete trigger phrases tied to user utterances.	4 / 5
Trigger Term Quality	Trigger terms ('reviewing rendered HTML', 'interactive components', 'design-system patterns', 'ARIA command elements') are relevant to the niche, but common natural phrasings users would say ('accessible name', 'screen reader', 'button has no label') are only weakly present, with no synonyms or file/role extensions.	3 / 5
Distinctiveness Conflict Risk	The trigger is clearly scoped to ARIA command naming in rendered HTML/components, distinguishing it from sibling accessibility skills; only minor overlap risk with broader accessibility review skills.	4 / 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/aria-command-name/SKILL.md
Commit: 30756a7

Reviewed: 7 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.