Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add commands/mtvrkan/senior-dev-kit/a11y-checkgit clone --depth 1 https://github.com/mtvrkan/senior-dev-kitWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/commands/mtvrkan/senior-dev-kit/a11y-check)<a href="https://agentmods.dev/commands/mtvrkan/senior-dev-kit/a11y-check"><img src="https://agentmods.dev/badge/commands/mtvrkan/senior-dev-kit/a11y-check.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00026 | $0.01564 |
| Opus 5 | $0.00013 | $0.00782 |
| Sonnet 5 | $0.00005 | $0.00313 |
| Haiku 4.5 | $0.00003 | $0.00156 |
Grade A, and why
a11y-check scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 6d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 103 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/a11y-check
Audit what was actually built for accessibility: $ARGUMENTS
/design-check asks whether the UI looks like its own product and checks the accessibility
invariants in one line. This is that line expanded into an audit, because those invariants are
where a distinctive interface most often fails and because a keyboard user does not care how good
the type pairing is. The requirement tables live in rules/100-web.md (web) and
rules/400-mobile.md (mobile) — read the one that matches the platform; they are not restated
here.
Unlike the other audit commands, findings here are fix-on-sight (global CLAUDE.md's A11Y:
line): report them, then route the fixes through ui-change in the same session rather than
recording them as debt. An accessibility defect is a broken product for the people who hit it.
Step 1 — Structure. One <h1>; heading levels descend without skipping; landmarks present and
unique (<main>, <nav>, <header>, <footer>); lists marked up as lists; <button> for
actions and <a href> for navigation — a <div onClick> is unreachable, unannounced and
unstyled by every assistive layer at once.
Step 2 — Keyboard. Tab through the whole flow in DOM order: every interactive element
reachable, nothing reachable that should not be, no trap, no positive tabindex. Escape closes
every overlay. Enter/Space activate what looks activatable. Custom widgets (menu, combobox, tabs,
tree) implement the APG keyboard pattern, not a partial one.
Step 3 — Focus. Visible indicator on every focusable element, ≥3:1 against its own surround,
never removed without a replacement. Focus moves into a dialog on open and returns to the trigger
on close. A route change moves focus to the new page's heading — otherwise a screen-reader user is
still in the old page. Sticky headers must not cover the focused element (2.4.11 — scroll-margin).
Step 4 — Names and forms. Every icon-only control has an accessible name; every input has a
real <label> (a placeholder is not one); the accessible name contains the visible label (2.5.3);
errors are associated via aria-describedby and announced (role="alert"); required and invalid
are conveyed to the API, not only in colour; autocomplete set on identity/payment fields (1.3.5);
and no field asks the user to re-enter information they already gave (3.3.7).
Step 5 — State reaches the API. aria-busy while submitting, aria-invalid on a failed field,
native disabled (or aria-disabled when the control must stay focusable and explain itself),
aria-expanded/aria-selected/aria-current where the widget claims them, and a live region for
content that changes without a page load. A spinner and a red border announce nothing.
Step 6 — Colour and contrast. Body ≥4.5:1, large text ≥3:1, UI components and focus indicators ≥3:1 — measured against the actual composited background, which is where glass, gradients, overlays and saturated colour fields fail. Nothing conveyed by colour alone. Check both themes, and check the disabled and placeholder states people habitually skip.
Step 7 — Targets and pointer. Interactive targets ≥24×24 CSS px (2.5.8), 44×44 recommended; adequate spacing between adjacent targets. Every drag has a single-pointer alternative (2.5.7). No hover-only affordance and no action bound to a path-based gesture without a simple alternative.
Step 8 — Reflow, zoom and motion. 320px width with no horizontal scrolling (1.4.10); 200% zoom
without loss of content or function; text-spacing overrides do not clip (1.4.12).
prefers-reduced-motion honoured, and nothing flashes more than three times a second.
Step 9 — Content. Meaningful alt on informative images and alt="" on decorative ones; link
text that makes sense out of context (never "click here"); lang on <html> and on any passage in
another language; captions on video and a transcript for audio; tables with real headers and scope.
Step 10 — Mobile, when it applies. Content descriptions on every control, Dynamic Type / font
scaling honoured (never a fixed size for body copy), touch targets 44pt/48dp, focus order sensible
under TalkBack/VoiceOver, safe areas respected, and the reduce-motion setting obeyed —
rules/400-mobile.md is canonical.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 6d ago First seen · 103 lines · 26 tokens per session scan A 61b2eb57fb5d
a11y-check is a command published in the GitHub repository mtvrkan/senior-dev-kit (5 stars, last pushed 5d ago), licensed MIT. It adds 26 tokens to every session and 1,564 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other commands, from other repositories
checklist
Generate a custom checklist for the current feature based on user requirements.
clarify
Identify underspecified areas in the current feature spec by asking up to 5 highly targeted clarification questions and encoding answers back into the spec.
specify
Create or update the feature specification from a natural language feature description.
analyze
Perform a non-destructive cross-artifact consistency and quality analysis across spec.md, plan.md, and tasks.md after task generation.
constitution
Create or update the project constitution from interactive or provided principle inputs.
converge
Assess the current codebase against the feature's spec, plan, and tasks, then append any remaining unbuilt work as new tasks to tasks.md so implement can complete it.