audit-accessibility

Ensure the plugin's custom UI components are accessible to users with screen readers and other assistive technologies.

Quality

56%

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 ./.agents/skills/audit-accessibility/SKILL.md

Quality

Content

62%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body presents a well-sequenced, validated workflow with concrete gradle commands and specific API checks. Its main weaknesses are verbatim repetition of the objective and a few steps that give direction without an executable method for applying the check.

Suggestions

Remove the duplicate objective restatement (the intro and '## Objective' sections repeat the same sentence) to recover tokens.

Make non-command checks executable: for contrast, name a tool/threshold (e.g., a contrast-ratio check or WCAG AA 4.5:1); for focus traversal, cite the specific Swing focus-traversal API to verify.

Move the manual-test-step guidance into a short referenced checklist (e.g., MANUAL_TESTING.md) so the main skill stays an overview.

Dimension	Reasoning	Score
Conciseness	The body is reasonably lean and mostly avoids explaining concepts Claude already knows, but it repeats the objective verbatim (header, intro, and '## Objective' sections all restate the same sentence), adding redundancy rather than new information.	2 / 3
Actionability	It gives concrete, runnable commands (./gradlew testClasses/test/verifyPlugin) and specific API checks (setAccessibleName/setAccessibleDescription), but several steps ('verify they meet WCAG contrast guidelines', 'handle focus traversal correctly') give direction without an executable method or example to apply them.	2 / 3
Workflow Clarity	The seven steps are clearly sequenced with a baseline-verify-report arc, an explicit verification checkpoint after changes (run tests + verifyPlugin again), and manual-test guidance, satisfying the validation-checkpoint requirement.	3 / 3
Progressive Disclosure	Content is organized into clear labeled sections, but everything is inline in a single SKILL.md with no references to separate detail files, and the manual-test/logging guidance (a self-contained checklist pattern) is embedded rather than split out.	2 / 3
	Total	9 / 12 Passed

Description

50%

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 states a clear objective and names the accessibility domain, but it lacks concrete actions and an explicit 'Use when' trigger clause. It is functional but reads as a goal statement rather than a precise, trigger-rich capability description.

Suggestions

Add an explicit 'Use when...' clause naming natural trigger phrasing, e.g. 'Use when auditing a plugin's UI for a11y, screen-reader support, keyboard navigation, or WCAG compliance.'

Replace the single objective verb with concrete actions: 'Audit plugin UI components for accessible names/descriptions, keyboard focus traversal, and color contrast.'

Include common a11y trigger terms users would say ('accessibility', 'a11y', 'WCAG', 'screen reader', 'keyboard navigation') to improve trigger matching.

Dimension	Reasoning	Score
Specificity	Names the domain ('plugin's custom UI components') and a target outcome ('accessible to users with screen readers and other assistive technologies'), but does not list concrete actions like auditing, setting names/descriptions, or fixing contrast; it states an objective rather than specific capabilities.	2 / 3
Completeness	It clearly answers 'what does this do' (ensure UI components are accessible), but there is no explicit 'Use when...' trigger clause telling Claude when to invoke it, which per the guidelines caps completeness at 2.	2 / 3
Trigger Term Quality	It includes natural user-facing terms ('accessible', 'screen readers', 'assistive technologies') but omits common variations like 'a11y', 'accessibility audit', 'WCAG', or 'keyboard navigation', so coverage of natural trigger phrasing is partial.	2 / 3
Distinctiveness Conflict Risk	The plugin/screen-reader framing gives it a recognizable niche, but without explicit triggers it could overlap with general UI-testing or plugin-quality skills, so it is only somewhat specific.	2 / 3
	Total	8 / 12 Passed

Validation

100%

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 — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository: flutter/flutter-intellij
Path: .agents/skills/audit-accessibility/SKILL.md
Commit: 21aaf0b

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