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

62%

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

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 well-structured with a clean overview and a correctly signaled one-level reference to an existing bundle file. Its weaknesses are motivational/ meta filler, the absence of any in-body executable example, and a missing re-validation loop after fixes.

Suggestions

Cut the opening motivation sentence and the meta "Explain" line; assume Claude knows why tooltip accessibility matters and keep only the actionable criteria.

Inline a minimal copy-paste tooltip snippet (role='tooltip' + aria-describedby + Escape dismissal) in the Fix section so the body is self-sufficient, keeping rule.md for framework-specific variants.

Add an explicit re-check step after Fix (e.g., re-verify keyboard focusability and Escape dismissal on the rendered markup) to close the validation feedback loop.

Dimension	Reasoning	Score
Conciseness	The body is mostly efficient (lean Quick Reference and sectioned Check/Fix/Code Review), but the opening motivation sentence and the meta "Explain the accessibility requirements..." line restate concepts Claude already knows and could be trimmed.	2 / 3
Actionability	It names concrete specifics (role='tooltip', aria-describedby, Escape-key dismissal, focusable trigger) but provides no executable code in the body itself — the working example is deferred to references/rule.md, leaving the guidance concrete yet incomplete.	2 / 3
Workflow Clarity	The Check → Fix → Explain → Code Review phases give a clear sequence and the Quick Reference acts as a checklist, but there is no fix → re-check validation/feedback loop after applying fixes.	2 / 3
Progressive Disclosure	The SKILL.md is a well-organized overview that clearly signals a single one-level-deep reference ("see `references/rule.md`"), which exists and holds the code examples and detailed guidance; content is appropriately split.	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 has a clear explicit "Use when" trigger and a specific what-statement, but its action list is narrow and the embedded "Create accessible tooltips" phrasing reads unnaturally. The broad review trigger also risks overlapping with sibling rule skills.

Suggestions

Lead with the concrete actions (e.g., "Reviews rendered HTML and templates for accessible tooltip markup: focusable triggers, aria-describedby, role='tooltip', and Escape-key dismissal") so the what is a list of specific actions, not a single verb.

Drop the awkward embedded "Create accessible tooltips" task title and add natural user terms such as "ARIA", "accessibility", and "tooltips" so trigger coverage matches how users actually phrase the request.

Sharpen the "Use when" clause to reference tooltip/ARIA accessibility specifically (rather than generic template/HTML review) to reduce overlap with sibling frontendchecklist skills.

Dimension	Reasoning	Score
Specificity	Names the domain ("templates, rendered HTML, or shared components") and an action ("Validate the final browser-facing markup"), but offers only one effective action rather than a comprehensive list of multiple concrete actions.	2 / 3
Completeness	It answers both what ("Validate the final browser-facing markup, not just the source framework abstraction") and when with an explicit "Use when reviewing templates, rendered HTML, or shared components..." trigger clause.	3 / 3
Trigger Term Quality	Relevant terms like "templates", "rendered HTML", "shared components", and "accessible tooltips" are present, but the awkward embedded phrase "Create accessible tooltips" and the absence of common variations (e.g., "ARIA", "accessibility", "tooltips" alone) leave coverage incomplete.	2 / 3
Distinctiveness Conflict Risk	The trigger phrasing "reviewing templates, rendered HTML, or shared components" overlaps heavily with sibling frontendchecklist HTML review skills; distinctiveness relies solely on the "accessible tooltips" qualifier.	2 / 3
	Total	9 / 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/accessible-tooltips/SKILL.md
Commit: 48405aa

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