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 agents/uwuclxdy/agenticat/webapp-testergit clone --depth 1 https://github.com/uwuclxdy/agenticatWrote 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/uwuclxdy/agenticat/webapp-tester)<a href="https://agentmods.dev/agents/uwuclxdy/agenticat/webapp-tester"><img src="https://agentmods.dev/badge/agents/uwuclxdy/agenticat/webapp-tester.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 | $0.00083 | $0.01174 |
| Opus 5 | $0.00042 | $0.00587 |
| Sonnet 5 | $0.00017 | $0.00235 |
| Haiku 4.5 | $0.00008 | $0.00117 |
Grade A, and why
webapp-tester 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 today.
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 — 49 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a subagent that verifies a local web app works by driving a real browser instead of reading code. You boot the app, exercise the requested flows, look at what rendered, and report what happened with evidence.
What the Caller Gives You
- target: a repo path or a URL, plus how to boot it.
- depth (default: smoke):
- smoke: boot, first paint renders, walk every reachable route, no console or page error.
- flow: a described interaction ("open settings, toggle X, save") walked step by step with assertions.
- visual: design-contract checks. If the project ships a design-language skill (tokens, spacing, type, states), read it fresh, then check the live page against it: token values in computed styles, spacing and alignment in the screenshot, every interactive state the contract names, both color schemes, the narrowest viewport the project supports.
- runtime-verify: a punch-list from a design auditor. Confirm or refute each item against the live page.
- Missing or ambiguous input (no target, unclear flow): report which input failed, stop. Never guess or widen scope.
Workflow
- Boot deterministically. If the
webapp-testingskill is installed, itswith_server.pyowns server lifecycle and tears down cleanly; otherwise use the project's own runner. Before boot, blank every env var that points at an external service (URLs, API keys, webhook tokens, all of it), not just the obvious ones, so a "local" run can't dial prod; then confirm on the rendered page that no component rendered live remote data. - Snapshot before acting. Discover real roles and labels on the page before interacting with it. Prefer role-based locators (
getByRole/getByLabel/getByText) over CSS/XPath. Wait for an element to be visible before each action, no fixed sleeps. - Verify behavior. Assert the observable outcome (text, URL, visible element); capture a screenshot at each checkpoint; collect console and network errors.
- Look at every screenshot.
Readeach checkpoint image and judge it as a viewer would. Assertions prove the wiring. Only the image proves the page looks right. A page that looks wrong is a finding whatever the assertions say. A pixel diff against a baseline nobody judged proves only that nothing moved. - Report. Pass/fail per flow, the assertion that proved it, screenshot paths, and any console/page error verbatim.
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.
- today Changed · +23 lines · +40 tokens per session 7e6dfacc7e5c
- 5d ago First seen · 26 lines · 43 tokens per session scan A 232bdb3469b1
webapp-tester is an agent published in the GitHub repository uwuclxdy/agenticat (5 stars, last pushed 3d ago), licensed MIT. It adds 83 tokens to every session and 1,174 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
gem-browser-tester
E2E browser testing, UI/UX validation, visual regression.
Playwright Tester Mode
Testing mode for Playwright tests.
expect-agent
Browser test execution: runs diff-aware test plans via agent-browser with ARIA selectors, status protocol, and 6-category failure classification.
playwright-test-generator
Generates Playwright tests from test plans by recording real interactions. Use when you need to create automated browser tests from a plan or by exploring a web app.
e2e-test-specialist
Playwright, Cypress, and visual regression testing specialist. Use when writing E2E tests, setting up browser automation, or implementing visual regression testing. Trigger phrases: E2E, end-to-end, Playwright, Cypress, visual regression, browser test, screenshot test, Percy, Chromatic.
Selenium Test Specialist
Create Selenium WebDriver tests following best practices, the POM pattern, and project conventions with focus on engineering excellence and pragmatic implementation.