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 skills add soumyachk101/VibeLens --skill a11y-auditgit clone --depth 1 https://github.com/soumyachk101/VibeLensWrote 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/skills/soumyachk101/vibelens/a11y-audit)<a href="https://agentmods.dev/skills/soumyachk101/vibelens/a11y-audit"><img src="https://agentmods.dev/badge/skills/soumyachk101/vibelens/a11y-audit/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/soumyachk101/vibelens/a11y-audit"><img src="https://agentmods.dev/badge/skills/soumyachk101/vibelens/a11y-audit.svg" alt="Reviewed on agentmods" width="80" 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.00071 | $0.01316 |
| Opus 5 | $0.00036 | $0.00658 |
| Sonnet 5 | $0.00014 | $0.00263 |
| Haiku 4.5 | $0.00007 | $0.00132 |
Grade A, and why
a11y-audit 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 11d 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.
Accessibility audit
Target: $ARGUMENTS (if empty, ask for the URL).
What this skill can and cannot do
inspect_localhost_ui gives you a rendered screenshot and a sanitized DOM with
real ids, classes, role and aria-* attributes. That is enough to catch the
common, high-frequency failures listed below by inspection.
It is not a substitute for axe-core, Lighthouse or a screen-reader pass. You cannot compute contrast ratios from a JPEG, you cannot tab through the page (the tool is read-only — no clicking, typing or scrolling), and you cannot observe focus order, live-region announcements or the computed accessibility tree. Say this in your report. Never claim a page is "WCAG compliant" on the strength of this audit; claim only that the issues you found are real.
Steps
-
Capture the page twice: once
viewport: "desktop"and onceviewport: "mobile", both withfullPage: true. Desktop shows the full structure; mobile is where tap-target and reflow failures appear. Raisedelayto 2000–3000 if the DOM comes back nearly empty — you cannot audit an unhydrated page. -
Check
summary.domTruncated. If it istruethe tree is partial, so scope your findings to what you actually saw and say which regions you could not reach. -
Work the DOM snapshot for structural failures:
- Images without alt. Every
<img>needsalt. A decorative image needsalt=""— absent and empty are different findings, so do not report an intentionalalt=""as a bug. - Controls with no accessible name. Icon-only
<button>s and<a>s with no text child and noaria-label/aria-labelledbyannounce as "button". Look for buttons whose only child is a collapsed<svg>placeholder — the sanitizer empties SVG internals, so an SVG-only button is easy to spot. - Inputs with no label. For each
<input>,<select>and<textarea>, find one of: a<label for="...">matching itsid, anaria-label, or anaria-labelledbypointing at an id that exists in the tree. A placeholder is not a label — it disappears on input and many screen readers skip it. - Heading order. List the headings in document order and flag skips
(
h1→h3), multipleh1s, and pages with noh1at all. Also flag text that looks like a heading in the screenshot (large, bold) but is a<div>or<p>in the DOM — that is invisible to a screen reader. - Landmarks. Note a page with no
<main>,<nav>orrole="main"; it forces screen-reader users to read linearly from the top. aria-hiddenon interactive elements androlevalues that contradict the tag (role="button"on a<div>with notabindex).
- Images without alt. Every
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.
- 11d ago First seen · 103 lines · 71 tokens per session scan A 3d23b9125c20
a11y-audit is a skill published in the GitHub repository soumyachk101/VibeLens (0 stars, last pushed 4d ago), licensed MIT. It adds 71 tokens to every session and 1,316 once invoked, about $0.0004 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 skills, from other repositories
accessibility-testing
Run automated WCAG audits, manual keyboard/screen reader testing, and CI a11y gates.
test-driven-development
Drives development with tests using the red-green-refactor loop. Use when implementing any logic, fixing any bug, or changing any behavior. Use when you need to prove that code works, when a bug report arrives, or when you're about to modify existing functionality.
frontend-ui-engineering
Builds production-quality, accessible, responsive user-facing UIs. Use when building or modifying interfaces and pages, creating components, implementing layouts, meeting WCAG accessibility requirements, managing state, or when the output needs to look and feel production-quality rather than AI-generated.
accesslint-diff
Diff a live page's accessibility violations against a baseline — by default compares uncommitted changes (stash-based), or pass --branch [ ] to diff against a branch. Reports only new violations introduced, violations fixed, and pre-existing count. Use scan for a full audit with no diffing.
screen-reader-testing
Test web applications with screen readers including VoiceOver, NVDA, and JAWS. Use when validating screen reader compatibility, debugging accessibility issues, or ensuring assistive technology support.
browser-testing-with-devtools
Tests in real browsers via Chrome DevTools MCP. Use when building or debugging anything that runs in a browser. Use when you need to inspect the DOM, capture console errors, analyze network requests, profile performance, or verify visual output with real runtime data. Requires the chrome-devtools MCP server to be…