accessible-tooltips

Use when reviewing templates, rendered HTML, or shared components related to Create accessible tooltips. Validate the final browser-facing markup, not just the source framework abstraction.

Quality

73%

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/accessible-tooltips/SKILL.md

Quality

Content

72%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 tight, well-structured review skill that cleanly offloads detail to a real one-level reference file. Its main weakness is actionability: inline guidance names the right ARIA attributes but offers no executable examples, leaving the concrete review/fix steps to be inferred or pulled from the reference.

Suggestions

Add one small inline code example of accessible vs. inaccessible tooltip markup so the Check/Fix sections are immediately executable without opening the reference.

Make the review workflow's verification step explicit (e.g., 'Confirm the tooltip opens on focus, dismisses on Escape, and survives a screen-reader pass') so validation is not merely implied.

Specify the exact ARIA roles/properties to look for in the Check section (role='tooltip', aria-describedby on the trigger) rather than only in the Fix section.

Dimension	Reasoning	Score
Conciseness	The body is lean and assumes Claude's competence with no concept padding or background exposition; every line (Quick Reference, Check/Fix/Explain/Code Review) earns its place, matching 'lean and efficient; every token earns its place'.	5 / 5
Actionability	It names concrete attributes to verify ('role=tooltip', 'aria-describedby', 'Escape key dismissal') but provides no inline executable examples or commands, and the concrete implementation guidance is deferred to the reference file, fitting 'some concrete guidance but incomplete; missing key details'.	3 / 5
Workflow Clarity	The Check/Fix/Explain/Code Review sections give a clear review sequence ('Flag exact elements, attributes, and routes'), and the skill is not destructive/batch so the validation cap does not apply, but explicit verification checkpoints are only weakly implied rather than stated, matching 'clear sequence with most checkpoints present; minor validation gaps'.	4 / 5
Progressive Disclosure	It is a short, well-organized overview that defers full implementation details to a clearly signaled one-level-deep reference (references/rule.md, a real file), matching 'clear overview with well-signaled one-level-deep references'.	5 / 5
	Total	17 / 20 Passed

Description

75%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 concise and clearly answers both what and when with a third-person voice and an explicit 'Use when' trigger, scoping the skill to tooltip accessibility review. It is slightly held back by a broad 'templates/rendered HTML/shared components' framing that risks overlap with sibling HTML review skills and by an implied rather than enumerated action list.

Suggestions

Lead the description with the concrete capability (e.g., 'Reviews tooltip markup for keyboard and screen-reader accessibility') so the 'what' is an explicit verb list rather than implied.

Add 'tooltip(s)' and 'ARIA' as natural keywords in the description body to strengthen trigger coverage beyond the skill name.

Tighten the trigger scope to mention tooltips explicitly to reduce overlap risk with other generic HTML/frontend review skills.

Dimension	Reasoning	Score
Specificity	Names the domain and several concrete actions ('reviewing templates, rendered HTML, or shared components', 'Validate the final browser-facing markup'), with minor gaps in coverage rather than a comprehensive action list, fitting the 'lists several specific actions; minor gaps' anchor.	4 / 5
Completeness	Has both a 'what' (validate rendered markup for accessible tooltips) and an explicit 'when' ('Use when reviewing templates, rendered HTML, or shared components'), but the 'what' is somewhat implied rather than a concrete verb list, landing at 'both what and when; when could be more explicit or specific'.	4 / 5
Trigger Term Quality	Includes natural review-oriented terms ('templates, rendered HTML, shared components') a user would plausibly say, though 'tooltips' itself appears only in the name and a few common phrasings are missing, matching 'good keyword coverage; a few natural terms missing'.	4 / 5
Distinctiveness Conflict Risk	Scoped to tooltip accessibility review which gives it a clear niche, though the broad phrasing ('templates, rendered HTML, or shared components') creates minor overlap risk with other HTML/frontend review skills, matching 'mostly distinct; minor overlap risk'.	4 / 5
	Total	16 / 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/accessible-tooltips/SKILL.md
Commit: 30756a7

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