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.

65

Quality

79%

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

78%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 well-structured and token-efficient, presenting a clear review workflow (Check/Fix/Explain/Code Review) with actionable before/after examples and a clean one-level pointer to references/rule.md for code and framework detail. Its only real weakness is minor repetition of the sensory-cue framing between the intro and Explain sections.

Suggestions

Remove the near-duplicate sensory-cue sentence from the Explain section since it restates the intro verbatim.

Add one short inline before/after markup snippet in the Fix section so the most common fix is visible without opening the reference.

Make the verification checkpoint explicit in the Code Review section (e.g. 'Run axe/Lighthouse; then navigate with a screen reader to confirm').

DimensionReasoningScore

Conciseness

The body is lean with short sections and bullets and assumes Claude's domain knowledge, but the opening sensory-cue sentence is repeated near-verbatim in the Explain section, a minor redundancy.

4 / 5

Actionability

Gives concrete, actionable guidance with before/after examples ('Instead of click the green button, use click the Submit button (green)') and specific items to flag; code examples live in the reference file, which is acceptable for an instruction-only skill.

4 / 5

Workflow Clarity

A coherent review sequence is present (Check -> Fix -> Explain -> Code Review) with verification guidance ('verify the fix with browser accessibility tooling or assistive tech'), though checkpoints are implicit rather than enumerated.

4 / 5

Progressive Disclosure

The body is a concise overview that clearly signals a single one-level-deep reference ('see references/rule.md') for full implementation details, code examples, and framework guidance; the referenced file exists and holds the detail.

5 / 5

Total

17

/

20

Passed

Description

80%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 strong: it pairs an explicit 'Use when' trigger with a concrete, sequenced set of review actions, giving Claude clear guidance on when and how to apply it. Its main weakness is that the trigger surface ('reviewing rendered HTML/components') is broad enough to overlap with sibling accessibility skills.

Suggestions

Tighten the trigger to name the rule more directly, e.g. 'Use when checking that instructions don't rely on color, shape, location, or sound alone', to reduce overlap with general accessibility review skills.

Add the natural term 'accessibility' or 'color-only instructions' so users searching by symptom find this skill.

Consider trimming 'where relevant' padding to keep the description lean.

DimensionReasoningScore

Specificity

Lists several concrete review actions ('inspect keyboard behavior, focus flow, accessible names, and screen-reader output') rather than vague language, though coverage is review-oriented and not the full capability surface.

4 / 5

Completeness

Explicitly answers both what ('Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output') and when ('Use when reviewing rendered HTML, interactive components, or design-system patterns') with concrete trigger phrases.

5 / 5

Trigger Term Quality

Includes natural terms users say ('rendered HTML', 'interactive components', 'design-system patterns', 'keyboard', 'screen-reader'), with a few common variations like 'accessibility' or 'color contrast' absent.

4 / 5

Distinctiveness Conflict Risk

Names the specific rule ('Avoid sensory-only instructions') giving it a niche, but the broad 'reviewing rendered HTML, interactive components, or design-system patterns' trigger overlaps with other accessibility review skills.

3 / 5

Total

16

/

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.