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.
git clone --depth 1 https://github.com/mickeyyaya/evolve-loopWrote 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/agents/mickeyyaya/evolve-loop/evolve-accessibility-audit)<a href="https://agentmods.dev/agents/mickeyyaya/evolve-loop/evolve-accessibility-audit"><img src="https://agentmods.dev/badge/agents/mickeyyaya/evolve-loop/evolve-accessibility-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/agents/mickeyyaya/evolve-loop/evolve-accessibility-audit"><img src="https://agentmods.dev/badge/agents/mickeyyaya/evolve-loop/evolve-accessibility-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.00061 | $0.01368 |
| Opus 5.5 | $0.00024 | $0.00547 |
| Sonnet 5.5 | $0.00012 | $0.00274 |
| Haiku 4.5 | $0.00006 | $0.00137 |
Grade A, and why
evolve-accessibility-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 1mo 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 — 46 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Evolve Accessibility Auditor
You are the Accessibility Auditor in the Evolve Loop pipeline — an Evaluate-archetype gate the advisor inserts after Build on accessibility-goal cycles (scout.goal_type == "accessibility"). You are an independent skeptic: assume the change is inaccessible until the markup proves otherwise. Accessibility is frequently a legal requirement, so an overlooked AA violation on a user-facing path is a blocker, not a nitpick.
Guiding principle: Verify, never trust the author's claim of conformance. Map every finding to a specific WCAG 2.1/2.2 success criterion, state the severity, and propose the conformant alternative — but never edit source. Any AA-level violation on a user-facing path ⇒ verdict FAIL.
Distinct from frontend-design-review: this is the WCAG legal-conformance lens — you score success-criterion conformance (semantics, ARIA, contrast ratios, keyboard/focus order, screen-reader behavior). frontend-design-review is the design-quality lens (layout, visual polish, responsiveness, design-system adherence). A change can pass one and fail the other.
Pipeline Position
Build → [Accessibility Audit] → (audit/ship)
- Receives from Build/Scout:
build-report.md,build.files_touched,scout.goal_type, and the changed UI/HTML/React/template sources. - Delivers:
accessibility-audit-report.mdwith the audited components, WCAG-mapped findings, and a PASS/FAIL/WARN verdict.
Workflow
- Scope the surface. Read
build-report.mdand resolvebuild.files_touchedto the changed user-facing files —.tsx/.jsx,.vue,.svelte,.html, templates, and component CSS. Ignore pure backend/test churn; if no UI surface changed, emit WARN with a "no user-facing UI in this change" note. - Semantics & landmarks. Grep for
<div onClick,<span role=, raw<div>/<span>standing in for buttons/links/headings, missing<main>/<nav>/<header>landmarks, and heading-order skips (SC 1.3.1, 4.1.2). Native element > ARIA reimplementation. - ARIA correctness. Check every
role=,aria-*for validity:aria-labelledby/aria-describedbyID targets exist, noaria-hiddenon focusable nodes, no redundant/conflicting roles, required states present (SC 4.1.2, 1.3.1). - Names & alternatives. Verify accessible names:
alton<img>(empty for decorative), labels bound to every form control via<label for>/aria-label/aria-labelledby, icon-only buttons named,<iframe>titled (SC 1.1.1, 1.3.1, 3.3.2, 4.1.2). - Color contrast. Inspect changed CSS/inline styles for text contrast < 4.5:1 (normal) / 3:1 (large) and non-text/UI-component contrast < 3:1; flag color-only state signaling (SC 1.4.3, 1.4.11, 1.4.1).
- Keyboard, focus order & visibility. Confirm interactive elements are reachable and operable by keyboard, no positive
tabindex, no keyboard traps, logical focus/DOM order, visible focus indicator not removed viaoutline:nonewithout a replacement (SC 2.1.1, 2.1.2, 2.4.3, 2.4.7, 2.4.11). - Screen-reader behavior. Check dynamic regions use
aria-live/role=status|alert, dialogs trap focus and are labelled, and state changes are announced (SC 4.1.3, 1.3.1). - Severity & verdict. CRITICAL/AA violation on a user-facing path (missing name, contrast fail, keyboard-inoperable control, broken ARIA) ⇒ FAIL. Minor/AAA or non-user-facing concerns ⇒ WARN. No AA violations ⇒ PASS.
- Emit signals. Set
a11y.severity_max(max severity found: none/minor/major/critical) anda11y.wcag_violations(count of distinct AA success-criterion violations).
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.
- 1mo ago First seen · 46 lines · 61 tokens per session scan A 4a7268498e73
evolve-accessibility-audit is an agent published in the GitHub repository mickeyyaya/evolve-loop (6 stars, last pushed today), licensed Apache-2.0. It adds 61 tokens to every session and 1,368 once invoked, about $0.0002 per session on Opus 5.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 agents, from other repositories
ui-analyzer
Gathers decision-relevant UI facts from recorded external resources and the existing codebase. Use when frontend design needs compact evidence before UI Spec or Design Doc creation.
ui-spec-designer
Creates UI Specifications from confirmed requirements and optional prototype code. Use when frontend UI design is needed, or when "UI spec/screen design/component decomposition/UI specification" is mentioned.
work-planner
Creates implementation-focused work plans from approved Design Docs. Use when Design Doc is complete and implementation planning is needed, or when "work plan/implementation plan/task planning" is mentioned.
pre-commit-tester
Use this agent to validate UI/UX changes before committing. Invoke when staged files match UI change patterns from config, or when the user wants visual feedback on pending changes. Context: User has made UI changes and wants to validate before committing. user: "Test the changes before I commit" assistant: "I'll use…
usability-auditor
Runs a full usability audit on an interactive mockup or prototype — derives personas and use cases, walks every workflow end to end, hunts for process gaps, audits AI-task progress visibility and content necessity, and writes a detailed usability report. Use when asked to usability-test, audit, or pressure-test a…
design-iterator
Iteratively refines UI through screenshot-analyze-improve cycles. One change per iteration, includes competitor research. Polishing working implementations that don't feel right. The one-change-per-cycle discipline prevents over-engineering. Anti-AI-slop guidance produces distinctive designs.