CtrlK
BlogDocsLog inGet started
Tessl Logo

button-name

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

62

Quality

73%

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

Quality

Content

70%

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

The skill is well-structured with clean progressive disclosure and a clear review workflow, but the body leans on generic templated phrasing and pushes all executable examples into the reference file.

Suggestions

Inline one minimal good/bad button markup snippet in the Fix section so the body is self-contained for the common case.

Remove the repeated title-echo phrasing in the Explain and Code Review sections to tighten token use.

Collapse the generic "Explain" meta-instruction into the Fix section since it largely restates the rationale already implied by the rule.

DimensionReasoningScore

Conciseness

The body is mostly lean checklist-style content, but it repeats the templated title phrase ("affect Provide accessible names for buttons") and includes generic meta-sections ("Explain", "Code Review") that could be tightened; not below 2 since it avoids explaining basics Claude already knows.

2 / 3

Actionability

Gives concrete, actionable guidance ("Use inner text, aria-label, or aria-labelledby", "replace the button with a link"), but executable examples and copy-paste markup are offloaded to references/rule.md rather than present in the body, leaving key details one step away.

2 / 3

Workflow Clarity

As a simple single-purpose review skill it has an unambiguous Check → Fix → Explain → Code Review sequence, and the Code Review section explicitly names a verification step ("verify the fix with browser accessibility tooling or assistive tech").

3 / 3

Progressive Disclosure

The body is a concise overview with a clearly signaled one-level-deep pointer ("see references/rule.md"), and that reference file exists and is well-organized into Code Example, Best Practices, Tools & Validation, and Verification sections.

3 / 3

Total

10

/

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 answers both what and when with concrete inspection actions, but its trigger phrasing is partly templated and broad enough to risk overlap with sibling accessibility skills.

Suggestions

Lead the trigger with the user's natural phrasing, e.g. "Use when a button has no visible text label, or when the user mentions buttons, icon buttons, or screen-reader output."

Drop the awkward title-echo "related to Provide accessible names for buttons" and replace with plain terms like "accessible button labels".

Tighten the broad "interactive components, or design-system patterns" scope to button-specific contexts to reduce conflict with general accessibility skills.

DimensionReasoningScore

Specificity

Lists multiple concrete inspection actions — "Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output" — matching the multiple-specific-actions anchor.

3 / 3

Completeness

Explicitly states what (check semantics, keyboard, focus, accessible names, screen-reader output) and when ("Use when reviewing rendered HTML, interactive components, or design-system patterns"), satisfying both halves with an explicit trigger clause.

3 / 3

Trigger Term Quality

Includes relevant terms ("rendered HTML", "interactive components", "design-system patterns", "accessible names", "screen-reader") but misses common user phrasings like "button" and "accessibility", and the templated "related to Provide accessible names for buttons" reads unnaturally.

2 / 3

Distinctiveness Conflict Risk

The button-accessible-name niche is fairly specific, but the broad trigger "reviewing rendered HTML, interactive components, or design-system patterns" could overlap with other accessibility skills, so it is not yet a clearly distinct niche.

2 / 3

Total

10

/

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.