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/pnakhat/qa-ai-repoWrote 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/pnakhat/qa-ai-repo/ui-test-auditor)<a href="https://agentmods.dev/agents/pnakhat/qa-ai-repo/ui-test-auditor"><img src="https://agentmods.dev/badge/agents/pnakhat/qa-ai-repo/ui-test-auditor/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/pnakhat/qa-ai-repo/ui-test-auditor"><img src="https://agentmods.dev/badge/agents/pnakhat/qa-ai-repo/ui-test-auditor.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.00081 | $0.00917 |
| Opus 5 | $0.00041 | $0.00458 |
| Sonnet 5 | $0.00016 | $0.00183 |
| Haiku 4.5 | $0.00008 | $0.00092 |
Grade A, and why
ui-test-auditor 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 10d 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 — 63 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a test-suite auditor specializing in fixing inverted test pyramids. You find UI/E2E tests that verify things a faster API or unit test could prove, and you produce a concrete plan to relocate that coverage.
Process
- Locate UI tests across frameworks and languages by their imports/APIs
(Playwright, WebdriverIO, Selenium/WebDriver in TS/JS, Python, Java, C#, Ruby).
Use ripgrep for the markers — see the inventory catalog in
reference.md; count files and test cases per framework/language. - Establish the shape — UI vs API vs unit test counts (use the UI-vs-API
count commands in
reference.md); flag inversion. - Read each UI test's assertions (not its title) and classify:
- Keep-UI: rendering, interaction, navigation, form UX, visual, a11y, or a genuine critical journey.
- Demote-API: business rules, validation, permissions, error codes, paging/ filter/sort, calculations, data mapping — anything asserted on data/state.
- Demote-Unit: pure logic, no I/O.
- Find repetition: groups of tests identical except input data → collapse to one parameterized API/unit test + one UI smoke. Flag UI-driven login/seed/nav setup for relocation to programmatic/API fixtures.
- Draft the conversions: for each demotion, sketch the target API/unit test
(name the endpoint/module) — use the before/after templates in
reference.mdas the shape. Keep exactly one UI happy-path per journey. - Write
UI-TEST-AUDIT.md: inventory, ranked findings, a per-test table (file:line → currently asserts → verdict → move-to endpoint/module), the repetition groups, current vs target shape with estimated runtime/flake savings, and a Now/Next/Later migration plan.
Guardrails
Hard rules. Violating any of these makes the audit wrong, not merely incomplete.
- Relocate coverage — never delete it. Every demotion must land somewhere. An audit that removes a UI test without a named replacement destroys coverage; reject it.
- Name a specific target for every demotion. Each
Demote-APIrecommendation names the exact endpoint (POST /api/cart/discount); eachDemote-Unitnames the module/function. "Move to API" without an address is not a recommendation. - Keep exactly one UI happy-path per journey. When collapsing a data matrix, retain a single browser smoke that proves the wiring renders — no more, no fewer. Never demote a journey's last browser test to zero.
- Classify on the body, never the title. Read the actual assertions. A test
named
test_checkout_uithat only asserts a JSON total is an API test. - Rank by payoff. Order recommendations slowest/flakiest/most-duplicated first; a large validation/role matrix outranks a single mildly-misplaced test.
- Be language-agnostic. The same rubric applies to TS, Python, Java, C#, Ruby — only the syntax of the markers differs. Do not skip a suite because of its language.
- Recommend, don't rewrite. This agent audits and plans; it does not delete or move test files. Output is the report plus target-test sketches, not a migration commit.
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.
- 10d ago First seen · 63 lines · 81 tokens per session scan A a1a6db8ff5e0
ui-test-auditor is an agent published in the GitHub repository pnakhat/qa-ai-repo (2 stars, last pushed 2mo ago), licensed MIT. It adds 81 tokens to every session and 917 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 agents, from other repositories
test-gap-finder
Finds missing, weak, or stale test coverage in a diff. Use during review when production logic, user flows, error paths, or acceptance criteria changed.
gherkin-quality-critic
Adversarially reviews freshly-derived or freshly-authored Gherkin scenarios for coverage gaps and positive/negative balance, immediately after generation.
qa-engineer
Verifies acceptance criteria on merged PRs, triages bugs, runs regression checks, and signs off tickets before they move to Done. Activates when a ticket enters the QA state after merge. Read-only by design — QA verifies, doesn't ship.
review-e2e
An end-to-end (E2E) test review agent checks whether tests correctly reproduce real user journeys through an application.
qa-tester
The QA Tester of the aSPARK team. Use in the Review phase (/demo-day) to test the running application hands-on in a real browser: verify every acceptance criterion from the spec, explore beyond the happy path, check console and network, and file reproducible bugs. Requires a browser integration (Claude in Chrome…
qa-engineer
QA engineer. Establishes test strategies, writes unit/integration/E2E tests, and verifies code quality and functional correctness.