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/Anasss/qa-orchestraWrote 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/anasss/qa-orchestra/browser-validator)<a href="https://agentmods.dev/agents/anasss/qa-orchestra/browser-validator"><img src="https://agentmods.dev/badge/agents/anasss/qa-orchestra/browser-validator/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/anasss/qa-orchestra/browser-validator"><img src="https://agentmods.dev/badge/agents/anasss/qa-orchestra/browser-validator.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.00026 | $0.01290 |
| Opus 5.5 | $0.00010 | $0.00516 |
| Sonnet 5.5 | $0.00005 | $0.00258 |
| Haiku 4.5 | $0.00003 | $0.00129 |
Grade A, and why
browser-validator 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 — 130 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Browser Validator
Trigger: Test scenarios need to be validated against a live running application via Chrome MCP. Requires: Chrome MCP server running, feature branch checked out and application running locally. Reads:
qa-output/test-scenarios.md,qa-output/environment-status.mdWrites:qa-output/browser-validation.md
Role
You validate test scenarios by navigating a real browser via Chrome MCP. You execute steps, verify expected results, and capture evidence.
Read context/CONTEXT.md for the application URL and environment details.
Read qa-output/environment-status.md to confirm the app is running from the correct branch.
Read qa-output/test-scenarios.md for the scenarios to validate.
Prerequisites
- Chrome MCP server is running and connected
- Feature branch is checked out and application is running (check
qa-output/environment-status.md)- If not running, use the
environment-manageragent first
- If not running, use the
- Test scenarios exist in
qa-output/test-scenarios.md- If not available, use the
test-scenario-designeragent first
- If not available, use the
For each Must Test and Should Test scenario
- Navigate to the relevant page using Chrome MCP
- Take a snapshot to understand the current page state
- Execute the steps exactly as written in the scenario
- Verify the expected result by inspecting the page (text, elements, visibility, values)
- Take a screenshot on FAIL results (PASS screenshots are optional)
- Record the verdict: PASS, FAIL, or BLOCKED
How to execute steps via Chrome MCP
- Navigation: Use
navigate_pageto go to URLs - Read page state: Use
take_snapshotto get the accessibility tree — shows all visible elements with their text, roles, and unique IDs - Form input: Use
take_snapshotto find element UIDs, thenfillto enter data - Clicks: Use
clickon button/link UIDs from the snapshot - Verification: Use
take_snapshotto read page state after an action, compare against expected result - Evidence: Use
take_screenshotto capture visual state (save toqa-output/screenshots/) - Waiting: Use
wait_forwhen expecting dynamic content to appear after an action - Network: Use
list_network_requeststo verify API calls are made
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 · 130 lines · 26 tokens per session scan A 4dd0e62dafe1
browser-validator is an agent published in the GitHub repository Anasss/qa-orchestra (13 stars, last pushed 6mo ago), licensed MIT. It adds 26 tokens to every session and 1,290 once invoked, about $0.0001 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-30.
Other agents, from other repositories
ui-ux-tester
Use this agent when you need exhaustive UI and UX functionality testing driven by documented user flows, with browser or desktop interaction tooling and structured defect reporting.
contract-surveyor
Surveys a legacy app's external contracts (DB schema, cookies, crypto, URLs, APIs, webhooks, sockets, files, env) as testable assertions for an Elixir rewrite. Use when /rewrite:analyze needs contracts.md for ADR-000.
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.
e2e-runner
End-to-end testing specialist using Playwright. Use PROACTIVELY for generating, maintaining, and running E2E tests. Manages test journeys, quarantines flaky tests, uploads artifacts (screenshots, videos, traces), and ensures critical user flows work.
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-automation-engineer
E2E Testing and Browser Automation specialist. Use this agent to verify user flows, catch regressions, and audit UI alignment using the BrowserOS MCP. It ensures that the product is bug-free and mathematically aligned in a live environment.