CtrlK
BlogDocsLog inGet started
Tessl Logo

sensory-instructions

Use when reviewing rendered HTML, interactive components, or design-system patterns related to Avoid sensory-only instructions. Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output where relevant.

58

Quality

67%

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/sensory-instructions/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 a clean overview pointing to a real one-level reference, but it is held back by redundant restating of the same guidance across sections, conceptual explanation Claude already knows, and verification guidance that stays abstract.

Suggestions

Collapse the overlapping Quick Reference, Check, and Explain sections into one consolidated checklist to remove repetition and concept restatement.

Add a short in-body markup example (bad vs. good, e.g. 'Required fields are marked in red' vs. 'marked with an asterisk (*)') so the Fix is copy-paste ready without opening the reference.

Replace the vague 'browser accessibility tooling or assistive tech' with a named verification step, e.g. 'Confirm with a screen reader that the instruction is perceivable without color/position.'

DimensionReasoningScore

Conciseness

The Quick Reference, Check, Fix, and Explain sections restate the same guidance (no color/shape/location/sound alone; add text labels; combine cues), and the Explain section recounts concepts Claude already knows ('color-blind users cannot distinguish color-only cues'), so it is mostly efficient but could be tightened and trimmed of redundancy.

2 / 3

Actionability

The Fix section gives a concrete before/after ('click the green button' → 'click the Submit button (green)'), but the body has no markup example and the Code Review verification ('browser accessibility tooling or assistive tech') is vague, leaving guidance concrete yet incomplete.

2 / 3

Workflow Clarity

The Check → Fix → Explain → Code Review sections imply a loose sequence, but there is no explicit ordering or validation checkpoint, matching the anchor for a present sequence with missing or implicit checkpoints.

2 / 3

Progressive Disclosure

The body is a concise overview that clearly signals a one-level-deep reference ('For full implementation details, code examples, and framework-specific guidance, see references/rule.md'), and that file exists, fitting the anchor for a clear overview with well-signaled one-level references.

3 / 3

Total

9

/

12

Passed

Description

77%

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 structurally complete with an explicit 'Use when' trigger and a list of concrete review actions, but its actions describe generic accessibility auditing rather than the sensory-only-instructions task specifically, and its trigger terms lean technical over natural user phrasing.

Suggestions

Replace the generic audit actions with the skill's actual task, e.g. 'Find instructions that rely on color, shape, location, or sound alone and add text-label alternatives.'

Add natural trigger terms users would say — 'color-only instructions', 'sensory characteristics', 'WCAG 1.4.1' — alongside the existing technical vocabulary.

Tighten the distinctiveness by leading with the sensory-instructions niche so it does not read like a catch-all accessibility-review skill.

DimensionReasoningScore

Specificity

Lists multiple concrete actions — 'reviewing rendered HTML, interactive components', 'Check native semantics', 'inspect keyboard behavior, focus flow, accessible names, and screen-reader output' — matching the anchor for listing several specific actions rather than vague language.

3 / 3

Completeness

It explicitly answers both when ('Use when reviewing rendered HTML, interactive components, or design-system patterns related to Avoid sensory-only instructions') and what ('Check native semantics first, then inspect...'), satisfying the anchor for clear what-and-when with explicit triggers.

3 / 3

Trigger Term Quality

Terms like 'native semantics', 'accessible names', and 'screen-reader output' are technical jargon; it misses the natural phrasing a user would say for this specific rule ('color-only instructions', 'sensory characteristics', 'don't rely on color'), so it has some relevant keywords but lacks common variations.

2 / 3

Distinctiveness Conflict Risk

The bulk is generic accessibility-audit language (semantics, keyboard, focus, accessible names, screen-reader output) that would overlap with sibling accessibility skills; only the trailing 'related to Avoid sensory-only instructions' phrase narrows it, fitting the 'somewhat specific but could overlap' anchor.

2 / 3

Total

10

/

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.