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

61%

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

65%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 a compact, well-structured overview with excellent progressive disclosure to a genuinely detailed references/rule.md. Its weaknesses are templating artifacts: Quick Reference/Check/Fix largely repeat each other, and the Code Review section is generic accessibility boilerplate that doesn't match the inclusive-language topic, which blurs the workflow.

Suggestions

Merge the Quick Reference bullets into the Check section (or vice versa) so each guidance item is stated once, freeing the Fix section to hold the top avoid→use-instead pairs from references/rule.md.

Rewrite the Code Review section for this topic — e.g. "In code reviews, flag identifiers and comments like sanityCheck, dummy data, master/slave, or crazy edge case and suggest the neutral alternatives from the reference table" — instead of the generic roles/focus/keyboard boilerplate.

Replace the misplaced verification line with a language-appropriate check, such as re-reading all user-facing strings (errors, empty states, placeholders) against the checklist in references/rule.md.

Dimension	Reasoning	Score
Conciseness	The body is short and mostly lean, but the same guidance is stated three times — "Replace ableist terms with neutral alternatives", "Use gender-neutral language (they, users)", "Avoid idioms..." appear in both Quick Reference and Fix, and Check repeats them again — so it could be meaningfully tightened rather than just trimmed at the margins.	3 / 5
Actionability	The guidance names concrete search terms ("crazy, lame, blind to", "he/she defaults"), gives specific alternatives ("they, users, people"), and points to references/rule.md which contains a full avoid/use-instead table and code examples; the only gaps are that the ableist-term replacements are not named inline and "cultural bias" checking is left vague.	4 / 5
Workflow Clarity	Check → Fix → Explain gives a recognizable review sequence, but the "Code Review" section is generic accessibility boilerplate ("roles, labels, focus behavior, or keyboard interactions") with the garbled phrase "interactive states that affect Use inclusive language", and the verification step ("verify the fix with browser accessibility tooling or assistive tech") doesn't fit a wording rule, leaving checkpoints implicit.	3 / 5
Progressive Disclosure	The body is a well-sectioned ~40-line overview and the single clearly-signaled reference ("For full implementation details, code examples, and framework-specific guidance, see references/rule.md") resolves to a real one-level-deep file holding the term-mapping table, examples, checklist, and verification steps — an appropriate split with easy navigation.	5 / 5
	Total	15 / 20 Passed

Description

58%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 has an explicit 'Use when...' trigger and several concrete inspection actions, but it is clearly a generic accessibility-review template: it never describes what this skill actually does (review and replace exclusionary language) and the rule title appears pasted awkwardly into the trigger clause. It would be hard for a user — or the model — to distinguish this skill from other accessibility skills on description alone.

Suggestions

State the actual capability in the description, e.g. "Reviews user-facing content and code for ableist, gendered, or exclusionary terminology and suggests neutral replacements (see the avoid/use-instead mapping in references/rule.md)."

Replace the template trigger with natural phrasing tied to the topic, e.g. "Use when reviewing UI copy, error messages, docs, or code comments for inclusive language, ableist terms, or gendered wording."

Remove the generic keyboard/focus/screen-reader action list (or trim to "check rendered text") since those actions belong to other accessibility skills and create trigger overlap.

Dimension	Reasoning	Score
Specificity	The description lists several concrete actions ("Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output"), but these are generic accessibility-inspection actions that never state the skill's actual capability — reviewing/replacing exclusionary language — so coverage of the 'what' is incomplete rather than having only minor gaps.	3 / 5
Completeness	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...") are explicitly present, but the 'when' clause is weakened by the awkward "related to Use inclusive language" phrasing and the 'what' is misaligned with the skill's purpose, so it falls short of the clearly-explicit anchor 5.	4 / 5
Trigger Term Quality	"inclusive language" is the one strong natural keyword a user would say, alongside "rendered HTML" and "interactive components", but common synonyms users actually use are missing (ableist language, gendered language, offensive wording, biased terminology), and the trigger phrase "related to Use inclusive language" reads as a glued-in rule title rather than natural phrasing.	3 / 5
Distinctiveness Conflict Risk	The only differentiator from sibling accessibility-review skills is the phrase "related to Use inclusive language"; the triggers ("reviewing rendered HTML, interactive components, or design-system patterns") and inspection actions describe generic accessibility review, so it would overlap with many similar skills in the same family.	3 / 5
	Total	13 / 20 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: 7bfd868

Reviewed: 1 day 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.