CtrlK
BlogDocsLog inGet started
Tessl Logo

workspace-brfis/create-accessible-modals

Build accessible dialogs/modals in the frontend

72

Quality

90%

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

Overview
Quality
Evals
Security
Files

Quality

Content

100%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 an exemplar of a focused accessibility skill: lean, fully actionable, with a clear sequenced workflow anchored by an explicit verification checklist and a single appropriately-split reference.

DimensionReasoningScore

Conciseness

The body is lean and assumes Claude's competence — it gives requirements and a compact executable example without explaining what a modal, ARIA, or basic HTML is, so every token earns its place.

5 / 5

Actionability

A complete copy-paste native `<dialog>`/`showModal()` example plus specific attributes (aria-labelledby, aria-describedby, aria-modal, tabindex=-1, aria-invalid) and concrete keyboard rules cover the common cases.

5 / 5

Workflow Clarity

A clear build-to-verify sequence is capped by an explicit 8-item verification checklist, with a feedback loop ('document the exception and test the resulting behavior rather than assuming the library is correct') for error recovery.

5 / 5

Progressive Disclosure

SKILL.md is a clear overview of actionable requirements, with rationale and sources split into a single well-signaled one-level-deep reference (references/research.md, verified to exist), giving easy navigation.

5 / 5

Total

20

/

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 specific and well-scoped to a distinct niche, but it lacks an explicit natural-language trigger ('Use when...') clause, relying instead on a scope clarification that does not give Claude concrete trigger phrases.

Suggestions

Add an explicit trigger clause, e.g. 'Use when the user asks to create, fix, or review a modal dialog, popup, or dialog box for keyboard and screen-reader accessibility.'

Include common synonyms users say ('popup', 'lightbox', 'dialog box') to improve trigger-term coverage.

Reframe 'use this for implementation and review, not for generic visual styling' as a positive trigger plus a negative boundary so the 'when' is as concrete as the 'what'.

DimensionReasoningScore

Specificity

The description enumerates multiple concrete capabilities — 'semantics, focus management, keyboard behavior, inert background content, form errors, and verification' — giving comprehensive coverage of the modal accessibility surface, matching the level-5 anchor.

5 / 5

Completeness

The 'what' is clear, but the only 'when'-ish guidance is the scope clarification 'use this for implementation and review, not for generic visual styling' — there is no explicit 'Use when...' trigger clause, which caps completeness at 3 per the rubric guideline.

3 / 5

Trigger Term Quality

Natural terms like 'modal dialogs', 'accessible modal', and 'dialog' are present, but common synonyms a user would actually say ('popup', 'lightbox', 'dialog box') are missing, so it sits just below comprehensive.

4 / 5

Distinctiveness Conflict Risk

'Create or improve accessible modal dialogs' carves a clear niche and the explicit negative boundary 'not for generic visual styling' minimizes conflict with adjacent styling or general accessibility skills.

5 / 5

Total

17

/

20

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

Reviewed

Table of Contents