inclusive-language

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

Quality

67%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/inclusive-language/SKILL.md

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 good progressive disclosure to a real reference file, but it suffers from redundant restatement across sections and lacks inline concrete replacement mappings and an explicit verification step.

Suggestions

Collapse the duplicated guidance across Quick Reference/Check/Fix/Explain into a single concise checklist so each token earns its place.

Inline a compact replacement mapping (e.g., a short avoid→use table) so the Fix section is actionable without opening the reference.

Add an explicit verification step (e.g., re-read changed text to confirm meaning is preserved and no new bias introduced) to complete the check→fix→verify workflow.

Dimension	Reasoning	Score
Conciseness	The body is mostly lean, but Quick Reference, Check, Fix, and Explain restate the same points (ableist terms, gender-neutral language, blame-free errors, avoid idioms) and the opening sentence plus Explain both restate 'language shapes experience,' so it could be tightened by de-duplicating.	2 / 3
Actionability	Concrete guidance names specific banned terms (crazy, lame, blind to) and specific alternatives (they, users, people), but the full replacement mapping and code examples live only in references/rule.md, leaving the inline Fix direction ('Replace ableist terms with neutral alternatives') somewhat abstract.	2 / 3
Workflow Clarity	The Check-then-Fix sequence is present and the single task is reasonably unambiguous, but there is no explicit verification step confirming replacements are correct, and the Explain/Code Review sections do not reinforce a clear sequence.	2 / 3
Progressive Disclosure	The body is a concise overview split into clear sections with a single, well-signaled one-level-deep pointer ('see references/rule.md') for full examples, and the referenced file exists, matching the clear-overview anchor.	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 explicit triggers and concrete actions, but the 'what' describes generic accessibility-interaction auditing rather than the skill's actual topic of inclusive language, creating misalignment and conflict risk with related accessibility skills.

Suggestions

Rewrite the 'what' to describe the actual skill: reviewing user-facing text for ableist, gendered, and exclusionary terms and replacing them with neutral alternatives, rather than keyboard/focus/screen-reader auditing.

Lead the trigger with the natural user phrase ('Use when reviewing or writing user-facing text for inclusive, non-discriminatory language') and add common variations like 'accessible wording' or 'non-discriminatory language'.

Drop the generic 'check native semantics, keyboard behavior, focus flow' clause, which belongs to a different accessibility skill and raises conflict risk.

Dimension	Reasoning	Score
Specificity	Lists multiple concrete actions—"Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output"—matching the anchor for several specific concrete actions rather than a vague single action.	3 / 3
Completeness	Structurally answers both: an explicit "Use when..." clause gives the trigger, and the second sentence states what to do, satisfying the both-what-and-when anchor.	3 / 3
Trigger Term Quality	Includes some relevant terms ("rendered HTML," "interactive components," "Use inclusive language") but the framing is technical and the natural phrase a user would say ("inclusive language") is awkwardly embedded; common variations like "non-discriminatory wording" or "accessible language" are missing.	2 / 3
Distinctiveness Conflict Risk	The generic accessibility-review boilerplate (keyboard behavior, focus flow, screen-reader output) describes a different domain than inclusive language and would overlap with sibling accessibility skills, though naming "Use inclusive language" narrows it somewhat.	2 / 3
	Total	10 / 12 Passed

Validation

93%

Warnings & errors only

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

Criteria	Description	Result
metadata_version	'metadata.version' is missing	Warning

	Total	15 / 16 Passed

Repository: thedaviddias/Front-End-Checklist
Path: skills/inclusive-language/SKILL.md
Commit: 48405aa

Reviewed: about 13 hours ago

Table of Contents

Discovery Implementation Validation

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.