accessibility

Primary accessibility skill for VS Code. REQUIRED for new feature and contribution work, and also applies to updates of existing UI. Covers accessibility help dialogs, accessible views, verbosity settings, signals, ARIA announcements, keyboard navigation, and ARIA labels/roles.

Quality

75%

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

Quality

Content

82%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.

A highly actionable, well-structured skill whose VS Code-specific API guidance and copy-paste skeletons are its core strength. Conciseness and progressive disclosure are the only soft spots, due to generic ARIA/keyboard sections Claude already knows and the absence of any reference files to offload them.

Suggestions

Trim or move sections 6 (Keyboard Navigation) and 7 (ARIA Labels and Roles) into a reference file, keeping only VS Code-specific notes (focusBorder, keybinding syntax) inline to cut generic concepts Claude already knows.

Add a short 'Verify' step after the registration steps in sections 1-2 (e.g., confirm the dialog opens with the accessibility help keybinding when the feature has focus) to give the workflow an explicit validation checkpoint.

Consider splitting the full code skeletons into a references/ file and keeping a minimal example inline, so SKILL.md reads as a lean overview pointing one level deep.

Dimension	Reasoning	Score
Conciseness	Most tokens earn their place via VS Code-specific API detail (AccessibleViewProviderId, IAccessibleViewImplementation, signal service) and concrete skeletons; the only over-explanation is the generic keyboard-nav and ARIA-label basics in sections 6-7 that Claude already knows, which keeps it just below a 5.	4 / 5
Actionability	Copy-paste-ready TypeScript skeletons for the help dialog, accessible view, verbosity registration, and signal playback cover the common cases concretely, with exact file paths, enum entries, and registration calls rather than pseudocode.	5 / 5
Workflow Clarity	Sections 1-3 use clear numbered steps and a comprehensive end-of-file checklist acts as the verification checkpoint; not a 5 because there is no explicit validate->fix->retry feedback loop, though the work is additive rather than destructive so the cap-at-3 rule does not apply.	4 / 5
Progressive Disclosure	Well-organized into numbered sections plus a checklist and a 'Key Files' pointer to repo sources, with easy header-based navigation; not a 5 because no bundle files exist and all ~300 lines are inlined, with generic sections 6-7 that could live in a reference file.	4 / 5
	Total	17 / 20 Passed

Description

67%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.

A solid, domain-specific description that clearly states what it covers and when to use it, with a distinct VS Code accessibility niche. Its main weakness is trigger-term naturalness: the most user-facing phrases are in the body and 'contribution' is project jargon.

Suggestions

Move a few concrete trigger phrases from the body into the description (e.g., 'Use when adding a new panel, view, widget, or editor overlay') so the description carries natural keywords users actually say.

Replace or gloss 'contribution work' with plainer language like 'new UI features or extensions' to reduce jargon and broaden natural trigger coverage.

Lead with a crisp action verb ('Add accessibility support to...') instead of 'Covers' to push specificity from naming topics toward naming actions.

Dimension	Reasoning	Score
Specificity	Enumerates concrete VS Code accessibility components ('accessibility help dialogs, accessible views, verbosity settings, signals, ARIA announcements, keyboard navigation, and ARIA labels/roles') rather than vague language, though 'Covers' names topics more than the action verbs of the 5-anchor example, leaving minor gaps.	4 / 5
Completeness	Both what ('Covers accessibility help dialogs, accessible views...') and when ('REQUIRED for new feature and contribution work, and also applies to updates of existing UI') are answered explicitly, satisfying the equivalent-trigger-guidance bar, though the when uses some jargon and could be more specific.	4 / 5
Trigger Term Quality	Relevant keywords like 'new feature', 'contribution work', 'existing UI', and 'accessibility' appear, but 'contribution' is VS Code jargon and the most natural user phrases ('add a new panel', 'implement a widget') live in the body, not the description; common variations are missing.	3 / 5
Distinctiveness Conflict Risk	The 'VS Code accessibility' niche is clear and unlikely to fire for unrelated skills, with minor overlap risk only against a generic web-accessibility skill; not a 5 because the trigger phrasing is slightly jargon-laden.	4 / 5
	Total	15 / 20 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: posit-dev/positron
Path: .github/skills/accessibility/SKILL.md
Commit: 75a1182

Reviewed: ~12 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.