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.

55

Quality

62%

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/accessible-notifications/SKILL.md
SKILL.md
Quality
Evals
Security

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 clean progressive disclosure to a real reference file, but it suffers from redundant repeated guidance across sections, no in-body executable code, and a check→fix loop lacking an explicit verification checkpoint.

Suggestions

De-duplicate the overlapping aria-live/role guidance across Quick Reference, Check, and Fix, and drop the opening sentence that explains screen-reader basics Claude already knows.

Add a concrete in-body code snippet showing the accessible notification pattern (e.g., role='status' with aria-live='polite') instead of deferring all examples to references/rule.md, and replace 'adequate display time' with a specific guideline.

Add an explicit verification checkpoint after the Fix step (e.g., 'Confirm the announcement fires in a screen reader / verify aria-live is present on the rendered output') to close the check→fix loop.

DimensionReasoningScore

Conciseness

The body is mostly efficient, but the Quick Reference, Check, and Fix sections repeat the same aria-live/role guidance, and the opening sentence explains screen-reader basics Claude already knows, so it could be tightened.

2 / 3

Actionability

It gives concrete attribute values (role='alert'/'status', aria-live='polite'/'assertive'), but provides no in-body executable code (all examples are deferred to references/rule.md) and leaves 'adequate display time' vague, fitting the incomplete-guidance anchor.

2 / 3

Workflow Clarity

A Check→Fix sequence is present, but there is no explicit validation or verification checkpoint closing the loop, matching the 'sequence present but checkpoints missing' anchor.

2 / 3

Progressive Disclosure

The body is a concise, well-sectioned overview that points to a single one-level-deep reference (references/rule.md, verified present) clearly signaled for full details, matching the clear-overview anchor.

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 cleanly answers both what and when with an explicit 'Use when…' trigger, but its action vocabulary and trigger-term coverage are narrow and its trigger scope risks overlap with broader HTML/accessibility review skills.

Suggestions

List additional concrete actions beyond 'reviewing' and 'validating' (e.g., 'flag missing aria-live regions, suggest role corrections, audit dismiss handling') to lift specificity.

Add natural trigger variations users would actually say, such as 'screen reader announcements', 'ARIA live regions', 'toast/alert accessibility', or 'accessible alerts'.

Narrow the trigger scope so it is specific to dynamic notification/alert/toast markup rather than any rendered HTML review, reducing conflict with general accessibility skills.

DimensionReasoningScore

Specificity

It names the domain and the actions 'reviewing' and 'Validate the final browser-facing markup', but does not list multiple distinct concrete actions like 'flag missing aria-live' or 'suggest role corrections', so it falls short of the comprehensive-action anchor.

2 / 3

Completeness

It has an explicit 'Use when…' trigger clause for when, and 'Validate the final browser-facing markup, not just the source framework abstraction' for what, clearly answering both as required for the top anchor.

3 / 3

Trigger Term Quality

It includes relevant keywords ('templates', 'rendered HTML', 'shared components', 'notifications', 'accessible') a developer might say, but misses common natural variations like 'screen reader announcements', 'ARIA live regions', or 'accessible alerts', matching the 'some relevant keywords but missing variations' anchor.

2 / 3

Distinctiveness Conflict Risk

The trigger 'reviewing templates, rendered HTML, or shared components' is fairly broad and could overlap with general HTML or accessibility review skills, so it is somewhat specific but not a clearly conflict-free niche.

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.