CtrlK
BlogDocsLog inGet started
Tessl Logo

accessible-notifications

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

67

Quality

81%

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

SKILL.md
Quality
Evals
Security

Quality

Content

78%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.

A well-structured, lean skill body with concrete ARIA attribute guidance and exemplary progressive disclosure through a single clearly signaled reference file. Its main weaknesses are minor: a padded motivational opener, no inline code example, and vague persistence/display-time criteria in the Check and Fix sections.

Suggestions

Trim the opening motivational sentence about screen reader users and the 'Explain' section, or fold them into the reference, to remove explanation of concepts Claude already knows.

Replace vague persistence guidance ("persist long enough to be read", "adequate display time") with concrete criteria, e.g. a minimum display duration or a dismissible-with-text rule, so the Check step is verifiable.

Add one short inline markup example (e.g. a role='status' / aria-live='polite' div) in the Fix section so the most common case is answerable without opening references/rule.md.

DimensionReasoningScore

Conciseness

The body is lean and sectioned, but the opening sentence ("Without proper ARIA attributes, screen reader users miss critical notifications...") explains a concept Claude already knows, and the "Explain" section is mild meta-padding that could be trimmed.

4 / 5

Actionability

Attribute-level guidance is concrete ("role='alert' or role='status'", "aria-live='polite' or 'assertive'", with the polite/assertive semantics), but there is no inline code example and vague thresholds like "persist long enough to be read" and "adequate display time" lack concrete criteria.

4 / 5

Workflow Clarity

A coherent Check → Fix → Explain → Code Review sequence for a simple single-task review skill, with minor validation gaps: no method for verifying display persistence and no concrete timing criteria to check against.

4 / 5

Progressive Disclosure

The body is a clear overview with a well-signaled, one-level-deep reference ("For full implementation details, code examples, and framework-specific guidance, see references/rule.md"), and that file exists and delivers the promised code examples.

5 / 5

Total

17

/

20

Passed

Description

83%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.

A strong description that explicitly answers both what the skill does and when to use it, with concrete targets and a specific validation action. Its weaknesses are minor: missing natural trigger synonyms (ARIA, screen reader, toast) and an awkward embedded rule-name phrase ("related to Make notifications accessible").

DimensionReasoningScore

Specificity

The description enumerates specific targets ("reviewing templates, rendered HTML, or shared components") and a concrete action ("Validate the final browser-facing markup, not just the source framework abstraction"), with only minor coverage gaps (no mention of flagging or fixing guidance).

4 / 5

Completeness

Both parts are explicit: the "when" opens the description ("Use when reviewing templates, rendered HTML, or shared components related to..."), and the "what" is concrete ("Validate the final browser-facing markup, not just the source framework abstraction"). This clearly matches the anchor-5 example structure rather than the more generic 'when' of anchor 4.

5 / 5

Trigger Term Quality

Natural user-facing terms like "templates", "rendered HTML", "shared components", "notifications", and "accessible" are present, but common variations such as "ARIA", "aria-live", "screen reader", or "toast" are missing.

4 / 5

Distinctiveness Conflict Risk

Notification accessibility and rendered-markup validation form a clear niche with distinct triggers, though the generic "reviewing templates, rendered HTML" trigger phrase overlaps with closely related HTML-review sibling skills.

4 / 5

Total

17

/

20

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.

Validation — 15 / 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.