accessibility-agents: six routers, 108 skills, and a 7.0.3 tree with no 7.0 release

npm install runs the installer the install section asks you to run twice

Two commands sit under the install heading:

npm install
node scripts/install.mjs

Read those next to the manifest and the second line is not always a separate step. package.json registers the same file under the npm lifecycle name install, mapping install to node scripts/install.mjs. A plain npm install inside a clone therefore triggers the copier through the lifecycle, and the install heading still lists it as a line to type yourself. Run both deliberately and you have copied twice.

The manifest also sets private to true, so there is no registry install for a package named accessibility-agents. A clone plus a script is the only route described. The version there reads 7.0.3, type is module, and engines pins node at 20 or newer, a floor the install heading never mentions.

What the script does is narrow. It copies skills to ~/.agents/skills, the shared location Codex, Copilot, Gemini and Antigravity read, and writes the hook manifest for whichever clients are present. It never overwrites a hooks file or a skill you have edited, and a --dry-run flag previews the work. Because edited files are skipped, a second run after you have customised a skill leaves your version in place. That is the right default, and it is also why a partially applied install can sit there unnoticed.

Six routers, and three of the six headline claims that have no router

The usage section is a routing table with six rows. The section below it is a bullet list with six bullets. They do not line up. accessibility-lead takes HTML, JSX, TSX, Vue, Svelte, CSS and server templates. web-accessibility-wizard takes a full site or app audit rather than one change. document-accessibility-wizard takes Word, Excel, PowerPoint, PDF and ePub files. markdown-a11y-assistant takes Markdown documentation. developer-hub takes Python, wxPython, desktop apps, NVDA add-ons and accessibility tooling. github-hub takes issues, pull requests, releases, projects, actions, security, teams and wikis.

Three bullets have no row. Blocking unreviewed edits is a hook, not a skill. Rendering reports is a script that reads JSON findings, computes the score and shows the delta against the previous run. Supplying scanners is an MCP server exposing thirty-nine tools across axe-core, Office, PDF, ePub, markdown, veraPDF, Playwright behavioural scans, audit history and report rendering. None of those three is reachable by describing the problem, so the claim that six entry points route the rest holds for review and audit work and stops at the enforcement and reporting layer.

Those six then name a further 102 specialist, helper and reference skills by name, and the layout counts 108 directories under skills/. The other 102 stay invisible to the model until a router names one. Directories named kb-<domain> hold reference data such as rule tables, URL registries and formulas, which is part of how 108 skills sit inside a fixed context budget.

One guard script, four hook manifests, five target clients

The guarantee that separates this from a review prompt is a refusal: a hook denies a write to a user-facing file until the accessibility lead completes. The qualifier closing that sentence is the part worth reading, on every client that supports hooks. The layout describes hooks/ as one guard script and four client manifests, and the installer writes the hook manifest for whichever clients it finds on your machine.

So the strongest claim in the package reaches you through one file per client, four of them, while the opening line names five clients that read the single tree: Claude Code, Codex, GitHub Copilot, Gemini CLI and Antigravity. A sixth client able to read skills from ~/.agents/skills is not automatically a client whose writes get blocked. Availability and enforcement are two different installations of the same package, and only one of them is described with a count.

The block also has a direction. It gates writes, not reads and not the final commit, so what keeps an inaccessible file from landing is a pre-write check inside one client rather than a rule that survives leaving that client. Nothing in the package says whether a blocked write can be overridden from inside an agent session, which makes the escape hatch the first thing to establish before trusting the guard.

The project blurb says eleven specialists and Claude Desktop; the tree holds 108 skills

The repository summary and the routing table describe different sized products. The summary promises review agents for Claude Code, GitHub Copilot and Claude Desktop, and eleven specialists that enforce WCAG 2.2 AA. The table lists six entry points that dispatch 102 more, and the layout counts 108 directories under skills/. Eleven appears nowhere else in the package.

Claude Desktop is the other half of that gap. The opening line names Claude Code, Codex, GitHub Copilot, Gemini CLI and Antigravity as clients reading the one package natively, and the plugin section offers three routes: a Claude Code marketplace command, a Copilot plugin install, and adding the repository through the Codex plugin command. Claude Desktop is in the summary and in none of the routes.

A third identity problem sits in the metadata. The repository url in package.json is https://github.com/Community-Access/accessibility-agents.git, and the Claude Code plugin command points at Community-Access/accessibility-agents. The homepage recorded for the project is https://github.com/taylorarndt/a11y-agent-team, a different account under a different repository name. Whichever is current, one of the two is a leftover from an earlier arrangement, and anyone following the homepage from a directory listing lands somewhere other than the code they came from.

package.json reads 7.0.3 and the newest published tag stops at v6.0.0

The manifest declares version 7.0.3. The history section treats version 7.0 as a finished event: it replaced six hand-maintained per-client trees with this one package, and the plan, the phases and the measured impact live in docs/history/2026-09-modernization.md. The published releases stop at v6.0.0 on 2026-06-15, after v5.4.0 and v5.3.0 on the same May evening. The last push to the default branch landed 2026-09-23, more than three months after that newest tag.

So the modernization everyone is pointed at has no release of its own. Anyone pinning a version gets 6.0.0, whose own release title reads Accessibility Agents 6.0: Codex, Extensions, and Enforced Specialist Dispatch, sitting under a repository whose declared version has moved three patch releases past it. Anyone watching the release feed to see whether the one-package design shipped finds a June tag and a September tree.

There are two history files, not one. CHANGELOG.md sits in the repository root while the modernization record sits under docs/history/. The history section links the second and leaves the first unnamed. A release consistency script does exist, wired to verify:release as node scripts/check-release-consistency.js, so something is meant to catch disagreement between version and tags. What it currently reports is not in the project.

Fifteen gates, twelve verify scripts, and one deviation left unnamed

The verification section promises fifteen gates, each naming the standard it checks and what a failure would cost, including live sessions on Claude Code, Codex and Copilot. The manifest carries twelve verify-prefixed scripts: a skill validator, a spec check, a budget check against budgets.json, a findings contract test, the report renderer self test, a skill conformance check, a markdown accessibility lint run with --fail-on error, markdownlint-cli2, the MCP node test run, the markdown scanner test, a release consistency check and the live session script. verify itself runs node scripts/verify.mjs.

Two gates short of the advertised fifteen have two possible readings. Either one script covers more than one gate, or two gates have no named script behind them. The manifest does not settle which, and a reader counting scripts has no way to decide from the project.

The same section names the fifth standard, WCAG 2.2, and states that every criterion a finding cites traces to it. It also points at a conformance dossier holding the evidence, the measured results and the one documented deviation from the Agent Skills specification. That deviation is not named in the overview. A package advertising conformance to Agent Skills, AGENTS.md, Agent Plugins 1.0 and the Model Context Protocol leaves its single exception to a separate file, which is a defensible choice and an easy one to miss.

The always-on contract outbids the whole package

Two token numbers sit close together and disagree. The layout annotates AGENTS.md as the always-on contract, under 1,200 tokens, with CLAUDE.md holding one line that imports it. The usage section says the whole package costs about 1,100 tokens before you have said anything, on the grounds that the other 102 skills stay invisible until a router names one.

A single file capped above 1,200 tokens cannot sit inside a package measured at about 1,100. Either the 1,100 figure counts something other than the always-on contract, or the AGENTS.md ceiling is a limit the file sits well below, and the overview states both as though they measure the same thing. budgets.json is checked by verify:budgets through measure-context.mjs --check, so a machine-checked budget exists somewhere behind these numbers.

Two scripts answer the question from the other direction. npm run measure reports what the package costs per client, and npm run measure:dispatch reports what dispatching a specialist costs, which is the figure that decides whether 108 skills are cheap or merely deferred. The contributor rule caps each skills/<name>/SKILL.md body at 6 KiB and pushes the long tail into references/, which is the other half of how that count fits.

A JavaScript package that also ships a Go CLI and a Python lint config

The primary language is JavaScript and the manifest sets type to module, yet the top-level entries include go-cli/, ruff.toml, action/, vscode-extension/, templates/, .vscode/, budgets.json, manifest.json and example/. The layout section shows seven of the thirty-eight root entries and mentions none of those. The one package claim also coexists with .claude-plugin/, .codex-plugin/, plugin.json and manifest.json, four packaging files for the very per-client copies the opening line says were replaced.

The undocumented ones are easy to place. developer-hub routes Python, wxPython and NVDA add-on work, so ruff.toml at the root belongs to the Python tooling that hub covers. action/ and vscode-extension/ line up with the extension work named in the v6.0.0 release title. example/ holds a four-file fixture, README.md, document-testing-guide.md, index.html and styles.css, which reads as a document and web audit target for the two wizard skills.

The maintenance scripts turn the package on itself. fix:tables runs describe-tables.mjs --apply and fix:emoji runs strip-heading-emoji.mjs --apply, and verify:markdown runs .github/scripts/markdown-a11y-lint.mjs over the repository with --fail-on error. A scanner that audits link text, alt text, heading order, tables, emoji and diagrams is linting the repository that ships it, from its own continuous integration, which is the most convincing evidence in the tree.

Editorial conclusion

Adopt it when you want accessibility review and report rendering at a stated token cost, and when you can accept that the write guard reaches only the clients whose hook manifests exist on your machine. Before pinning anything, check that the version you install matches a tag you can see, because the manifest reads 7.0.3 while the newest published tag stops at v6.0.0, and read the conformance dossier to find the single deviation from the Agent Skills specification that the overview never names.

Frequently asked questions

Official sources

1. Community-Access/accessibility-agents on GitHub
2. License: MIT
3. Project website
4. README
5. Releases