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

71%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 clean, well-structured overview that appropriately offloads detailed tables and code examples to references/rule.md with clear navigation. Its main weakness is redundancy between the Quick Reference and Fix sections, which repeat the same guidance.

Suggestions

Collapse the overlap between Quick Reference and Fix so the four inclusive-language principles appear once, with Fix focused on how to apply them.

Trim the opening conceptual sentence ('Language shapes experience...') since it is restated in rule.md's 'Why It Matters' and is knowledge Claude already has.

Surface one inline replacement example pair (e.g., 'crazy -> unexpected') in the Fix section so the body is actionable without requiring rule.md for the most common case.

Dimension	Reasoning	Score
Conciseness	Mostly efficient and well-organized, but Quick Reference and Fix repeat nearly the same four bullets ('Replace ableist terms... Use gender-neutral... Avoid idioms... Write error messages that guide rather than blame'), and the opening sentence restates a concept Claude already knows, so it could be tightened.	3 / 5
Actionability	Concrete, specific guidance for an instruction-only skill: names exact terms to find ('crazy, lame, blind to', 'he/she defaults') and concrete replacements ('they, users, people'); the full alternatives table lives in rule.md, leaving only minor gaps.	4 / 5
Workflow Clarity	A clear Check -> Fix -> Explain -> Code Review sequence for a simple review skill, with a light verification mention ('note how to verify the fix with browser accessibility tooling or assistive tech'); detailed validation lives in rule.md so checkpoints are mostly present with minor gaps.	4 / 5
Progressive Disclosure	The body is a concise overview with well-signaled one-level-deep navigation ('For full implementation details, code examples, and framework-specific guidance, see references/rule.md'), and the referenced rule.md exists and holds the detailed tables and code examples.	5 / 5
	Total	16 / 20 Passed

Description

63%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 structurally complete with concrete actions and an explicit trigger, but it appears to be a generic accessibility-review template: the named capabilities (semantics, keyboard, focus, screen-reader) do not match the inclusive-language skill's actual purpose. This misalignment limits trigger quality and distinctiveness.

Suggestions

Rewrite the 'what' to describe inclusive-language actions (e.g., 'Flag ableist, gendered, or exclusionary terms and suggest neutral alternatives') instead of generic accessibility audit steps.

Add natural trigger terms users would actually say, such as 'ableist language', 'gender-neutral wording', 'non-discriminatory copy', and 'inclusive error messages'.

Narrow the 'when' clause to inclusive-language review contexts to reduce overlap with general accessibility/semantics skills.

Dimension	Reasoning	Score
Specificity	Lists several concrete review actions ('Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output'), though these describe a generic accessibility audit rather than inclusive-language work specifically, leaving minor coverage gaps.	4 / 5
Completeness	Has both a 'what' (check semantics, inspect keyboard/focus/accessible names/screen-reader output) and an explicit 'Use when...' trigger clause, but the 'what' is misaligned with the skill's actual inclusive-language purpose, keeping it below a 5.	4 / 5
Trigger Term Quality	Includes 'Use inclusive language' and 'rendered HTML, interactive components, design-system patterns' but misses natural synonyms users would say ('ableist language', 'gender-neutral', 'non-discriminatory'); most keywords are generic accessibility terms.	3 / 5
Distinctiveness Conflict Risk	The 'related to Use inclusive language' qualifier gives some niche, but the bulk of triggers (semantics, keyboard behavior, focus flow, screen-reader output) overlap heavily with general accessibility skills and could fire for the wrong skill.	3 / 5
	Total	14 / 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: 30756a7

Reviewed: 9 days 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.