CtrlK
BlogDocsLog inGet started
Tessl Logo

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.

56

Quality

65%

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

Quality

Content

62%

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

A well-structured, lean overview that correctly uses one-level progressive disclosure to a real reference file. It is held back by concept restatement and by giving direction rather than executable examples or explicit validation steps in the body itself.

Suggestions

Trim the explanatory restatement of screen-reader basics in the lead and Quick Reference; assume Claude knows them and keep only the rule-specific guidance.

Add a small inline markup example (a labeled vs unlabeled button) so the body is actionable without forcing a jump to rule.md, or surface rule.md's key code snippet inline.

Add an explicit verification checkpoint (e.g. 'Confirm the name appears in the accessibility tree; re-check after fixing') to make the Check→Fix→Verify loop concrete.

DimensionReasoningScore

Conciseness

The body is brief and sectioned, but much of it restates accessibility concepts Claude already knows ('Without an accessible name, screen reader users will only hear the role', 'Ensures users know the purpose of the interactive element') and duplicates the reference's explanatory framing, so it could be tightened.

2 / 3

Actionability

It points to concrete mechanisms ('aria-label', 'aria-labelledby', inner text) and lists what to inspect, but the body itself contains no executable code, commands, or a worked example — those live only in the referenced rule.md — so it instructs more than it gives copy-paste-ready guidance.

2 / 3

Workflow Clarity

The Check/Fix/Explain/Code Review sections imply a sequence, but there are no explicit validation checkpoints or a verify-fix feedback loop in the body for what is a review-then-fix task; this is left implicit.

2 / 3

Progressive Disclosure

The body is a concise overview with one clearly signaled, one-level-deep reference ('see references/rule.md'), which exists in the bundle; content is appropriately split and easy to navigate.

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 clearly answers both what the skill does and when to use it, with an explicit 'Use when' trigger and concrete review actions. Its weakness is trigger-term breadth (missing common variations like 'aria-label'/'icon button') and a somewhat broad opening that risks overlap with related accessibility skills.

Suggestions

Tighten the opening trigger to lead with the specific ARIA-naming task (e.g. 'Use when checking that buttons, links, and menuitems have accessible names') rather than the broad rendered-HTML/design-system framing.

Add common natural keywords users would say — 'aria-label', 'aria-labelledby', 'icon buttons', 'accessibility audit' — to broaden trigger coverage.

List a few more concrete distinct capabilities (e.g. flag missing labels, suggest native-element alternatives, verify with the accessibility tree) to push specificity toward the top anchor.

DimensionReasoningScore

Specificity

Names the domain (rendered HTML, interactive components, design-system patterns) and several concrete review actions ('Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output'), but these are review activities rather than the multiple distinct skill outputs the top anchor calls for.

2 / 3

Completeness

Opens with an explicit 'Use when reviewing...' trigger and states the what ('Provide accessible names for ARIA command elements' plus the inspection steps), clearly answering both what and when.

3 / 3

Trigger Term Quality

Includes relevant natural terms ('rendered HTML', 'interactive components', 'screen-reader output', 'accessible names') but omits common variations users would say such as 'ARIA labels', 'icon buttons', 'aria-label', or 'accessibility audit'.

2 / 3

Distinctiveness Conflict Risk

The ARIA command-name niche is fairly distinct, but the broad lead-in ('rendered HTML, interactive components, or design-system patterns') could overlap with sibling accessibility skills before the specific ARIA-name qualifier applies.

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.