CtrlK
BlogDocsLog inGet started
Tessl Logo

carousel-accessibility

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

57

Quality

66%

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/carousel-accessibility/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

63%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, appropriately split overview that leverages progressive disclosure correctly and gives an unambiguous review workflow. Its weaknesses are redundancy across the Check/Fix/Explain sections and the absence of any concrete markup example or attribute-level detail in the body itself.

Suggestions

Differentiate the Check, Fix, and Explain sections instead of restating the same four requirements — e.g., make Check list concrete attributes to inspect (aria-roledescription, aria-live, aria-pressed, tabindex) and Fix point to the specific code pattern in references/rule.md.

Inline one minimal markup snippet (a pause button with aria-pressed, or an aria-live slide region) so the body is actionable without opening the reference.

Trim the opening sentence about disorientation and WCAG, which explains concepts Claude already knows.

DimensionReasoningScore

Conciseness

The body is short but the Check, Fix, and Explain sections each restate the same four Quick Reference requirements with no added information, and the opening sentence explains carousel accessibility concepts Claude already knows — 'mostly efficient but could be tightened' rather than lean.

3 / 5

Actionability

Quick Reference names concrete requirements ('pause/stop controls', 'arrow keys', 'aria-live regions', 'prefers-reduced-motion'), but the body itself contains no code, selectors, or specific attributes, deferring all executable detail to references/rule.md — concrete guidance that is incomplete in the body.

3 / 5

Workflow Clarity

The Check → Fix → Explain → Code Review structure gives a clear, unambiguous sequence for this simple single-purpose review skill, though there is no explicit verification step after fixes (the Verification section exists only in the reference file).

4 / 5

Progressive Disclosure

The body is a lean overview with a clearly signaled, one-level-deep pointer ('For full implementation details, code examples, and framework-specific guidance, see references/rule.md') to a real, well-organized reference file with Code Example, framework guidance, and Verification sections.

5 / 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.

A solid description with an explicit use-when clause, clear scope guidance, and recognizable trigger terms, held back by an awkward sentence construction and missing common synonyms. It is distinguishable from generic skills but its templated phrasing risks collisions with sibling rules from the same source.

Suggestions

Rewrite 'related to Make carousels accessible' into a grammatical clause, e.g. 'Review templates, rendered HTML, or shared components for carousel accessibility (pause controls, keyboard navigation, ARIA).' to sharpen the 'what' and lift specificity.

Add common trigger synonyms such as 'slider', 'slideshow', or 'ARIA' so users phrasing the need differently still hit the skill.

DimensionReasoningScore

Specificity

The description names two concrete actions — 'reviewing templates, rendered HTML, or shared components' and 'Validate the final browser-facing markup' — but stops short of listing the specific checks (pause controls, ARIA, keyboard access), matching the '1-2 concrete actions, not comprehensive' anchor rather than the several-action level 4.

3 / 5

Completeness

It has both an explicit 'when' ('Use when reviewing templates, rendered HTML, or shared components...') and a clear 'what' ('Validate the final browser-facing markup'), but the awkward embedded phrase 'related to Make carousels accessible' garbles the what slightly, keeping it below the cleanly explicit level 5 example.

4 / 5

Trigger Term Quality

Natural terms like 'carousels', 'accessible', 'rendered HTML', 'shared components', and 'browser-facing markup' give good keyword coverage, but common synonyms such as 'slider', 'slideshow', 'ARIA', or 'a11y' are missing, so it falls short of the comprehensive level 5 anchor.

4 / 5

Distinctiveness Conflict Risk

Carousel accessibility is a clear niche with distinct triggers, but the boilerplate trigger phrasing ('reviewing templates, rendered HTML, or shared components related to...') would be shared verbatim by sibling frontend-checklist HTML rules, creating minor overlap risk with closely related 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.

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.