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.

59

Quality

68%

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

67%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 well-organized, concise overview that follows a clean progressive-disclosure pattern, delegating code and framework specifics to references/rule.md. It is held back by a lack of executable examples and some vague timing guidance in the body itself.

Suggestions

Add one small inline code snippet showing a correct role='status'/aria-live='polite' notification so the body is actionable without opening the reference.

Replace vague timing phrasing ('adequate display time', 'persist long enough') with the concrete duration ranges already in rule.md (e.g., success 3-5s, errors no auto-dismiss).

Tie the references/rule.md pointer to a specific section (e.g., 'For code examples and framework components, see references/rule.md') so the reference is signaled where relevant, not only at the bottom.

DimensionReasoningScore

Conciseness

The body is lean with short bulleted and sectioned guidance and defers detail to references/rule.md; minor over-explanation remains in the rationale intro sentence and the meta 'Explain' section.

4 / 5

Actionability

Concrete attribute guidance appears (role='alert'/'status', aria-live='polite'/'assertive') but the body has no executable code examples and leaves timing vague ('adequate display time', 'persist long enough to be read').

3 / 5

Workflow Clarity

For a single-purpose review skill the action is unambiguous ('Flag exact elements, attributes, and routes where the rendered HTML violates the rule') and the Check section supplies verification criteria; no explicit validation checkpoint is present, but none is required for a non-destructive review.

4 / 5

Progressive Disclosure

A concise overview with clear sections and a single one-level-deep pointer to references/rule.md (which exists); the reference is signaled generally at the bottom rather than tied to specific sections, and the body lightly duplicates content also in rule.md.

4 / 5

Total

15

/

20

Passed

Description

70%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 well-structured with an explicit 'Use when' trigger, clear target artifacts, and a useful emphasis on validating rendered markup over framework abstractions. It is slightly thin on action variety and on the most colloquial trigger synonyms (alerts/toasts/ARIA).

Suggestions

Add a couple more concrete verbs (e.g., 'audit', 'flag missing aria-live/role attributes') to broaden the action coverage beyond review/validate.

Include natural synonyms users say ('alerts', 'toasts', 'ARIA live regions', 'screen reader announcements') to improve trigger-term recall.

Sharpen the 'what' clause to name the accessibility outcome explicitly, e.g., 'Ensure dynamic notifications are announced to screen readers via ARIA live regions.'

DimensionReasoningScore

Specificity

Names the domain ('notifications accessible', 'browser-facing markup') and two concrete actions ('reviewing templates, rendered HTML, or shared components' and 'Validate the final browser-facing markup'), but coverage is limited to review/validate rather than a comprehensive action set.

3 / 5

Completeness

Both 'what' ('Validate the final browser-facing markup, not just the source framework abstraction') and 'when' ('Use when reviewing templates, rendered HTML, or shared components...') are present, with an explicit trigger clause; the 'what' could be slightly more explicit about the accessibility outcome.

4 / 5

Trigger Term Quality

Good natural keyword coverage ('templates', 'rendered HTML', 'shared components', 'notifications', 'browser-facing markup') that a developer would plausibly say, though synonyms like 'alerts', 'toasts', 'ARIA', or 'screen reader' are absent.

4 / 5

Distinctiveness Conflict Risk

It carves a clear niche (accessible notifications in rendered HTML) with distinct triggers, with only minor overlap risk against broader HTML-accessibility or general markup-review skills.

4 / 5

Total

15

/

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.

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.