plain-language

Use when reviewing rendered HTML, interactive components, or design-system patterns related to Write in plain 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/plain-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 well-structured, appropriately scoped overview that delegates detail to a real one-level reference, with concrete review and fix guidance. Main weakness is minor redundancy across the Check/Fix/Explain sections.

Suggestions

Merge or deduplicate the 'Explain' section (which restates the intro) and tighten overlap between 'Check' and 'Fix' to save tokens.

Add one concrete, executable check (e.g., a sentence-length or reading-level threshold command) to lift actionability toward fully executable guidance.

Make the verification step explicit (e.g., 'After edits, re-check reading level and confirm it meets the 8th-grade target') to turn the flow into a validate-and-confirm loop.

Dimension	Reasoning	Score
Conciseness	The body is short and mostly efficient, but the 'Explain' section restates the intro nearly verbatim and 'Check'/'Fix' overlap on defining terms and active voice. Not a 4 because these redundancies could be trimmed without losing information.	3 / 5
Actionability	Gives concrete, specific review guidance ('Review content for jargon, complex sentences, and unnecessary technical terms. Verify reading level...') and concrete fixes ('Simplify complex sentences. Define technical terms... Use short paragraphs and bullet points. Write in active voice.'). Not a 5 because there are no executable checks (e.g., a sentence-length threshold command) for an otherwise measurable rule.	4 / 5
Workflow Clarity	A clear Check -> Fix -> Code Review flow with a verification cue ('note how to verify the fix with browser accessibility tooling or assistive tech'). Not a 5 because the verification step is only lightly sketched rather than an explicit validate-and-confirm checkpoint.	4 / 5
Progressive Disclosure	A lean overview body with a single, clearly signaled one-level-deep pointer ('see references/rule.md') that resolves to a real file, plus a rule-page URL. Easy to navigate with no nested references.	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 has an explicit 'Use when' trigger and concrete actions, but the actions describe generic accessibility auditing rather than plain-language review, creating topical mismatch and overlap risk with other accessibility skills.

Suggestions

Rewrite the 'what' to name plain-language actions: check reading level, flag jargon and passive voice, simplify complex sentences, define technical terms.

Add natural trigger terms users would say ('plain language', 'reading level', 'jargon', 'simplify the wording') and a user-mention clause ('when the user asks to simplify or clarify copy').

Drop the generic a11y inspection actions (keyboard behavior, focus flow, screen-reader output) that belong to other accessibility skills to reduce conflict risk.

Dimension	Reasoning	Score
Specificity	Lists several concrete inspection actions ('Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output'), though these describe general accessibility auditing rather than plain-language review specifically. Not a 5 because the actions are off-topic for the skill and coverage of plain-language actions (reading level, jargon, sentence complexity) is absent.	4 / 5
Completeness	Provides both a 'when' ('Use when reviewing rendered HTML, interactive components, or design-system patterns related to Write in plain language') and a 'what' (the check/inspect actions). Not a 5 because the 'when' lacks user-mention trigger phrasing and the 'what' does not describe plain-language actions.	4 / 5
Trigger Term Quality	Includes some relevant terms ('rendered HTML', 'interactive components', 'design-system patterns') but misses the natural phrases a user would say for plain language ('plain language', 'reading level', 'jargon', 'simplify wording'). Not a 4 because common variations and synonyms for this skill's actual topic are missing.	3 / 5
Distinctiveness Conflict Risk	The 'related to Write in plain language' qualifier narrows it somewhat, but the listed actions (keyboard behavior, focus flow, screen-reader output) are generic accessibility review and would overlap heavily with sibling accessibility skills. Not a 4 because the action set is not distinct from general a11y review.	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/plain-language/SKILL.md
Commit: 30756a7

Reviewed: 15 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.