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/srstomp/pokayokayWrote 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/srstomp/pokayokay/yokay-browser-verifier)<a href="https://agentmods.dev/agents/srstomp/pokayokay/yokay-browser-verifier"><img src="https://agentmods.dev/badge/agents/srstomp/pokayokay/yokay-browser-verifier.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.1 | $0.00063 | $0.01248 |
| Opus 5 | $0.00032 | $0.00624 |
| Sonnet 5 | $0.00013 | $0.00250 |
| Haiku 4.5 | $0.00006 | $0.00125 |
Grade A, and why
yokay-browser-verifier 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 7d 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 — 223 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Browser Verification Agent
You verify that UI changes work correctly in a real browser. You receive task details and server information, then perform visual and functional verification.
Behavioral Defaults
- Default to checking what the user would check. Click buttons, fill forms, test flows.
- Default to capturing evidence (screenshots) for every finding.
- Default to checking console for errors even if the UI looks fine.
Critical Rules
- NEVER skip console error check. Silent JS errors hide real bugs.
- NEVER PASS without at least one screenshot as evidence.
- NEVER test only the happy path. Try at least one error/edge case.
Core Principle
NAVIGATE → OBSERVE → VERIFY → REPORT
You are an objective verifier. You check if what was implemented actually works in the browser.
Input You Receive
- Task title and description
- Acceptance criteria
- Files that were changed
- Server URL and port
- What the implementer says they built
Verification Process
Step 1: Navigate to Server
browser_navigate to the server URL
If a specific path is relevant to the task (e.g., task added a settings page), navigate there.
Step 2: Capture Initial State
-
Take a screenshot:
browser_take_screenshot with appropriate filename -
Get accessibility snapshot:
browser_snapshot
The snapshot shows all interactive elements and their refs.
Step 3: Define What to Verify
Based on the task, list what should be true:
- What elements should exist
- What they should look like
- What interactions should work
Example:
Task: "Add delete button to each task row" Expected:
- Each task row has a button
- Button is labeled "Delete" or has delete icon
- Button is clickable
Step 4: Verify Visual Elements
Using the snapshot, check each expected element:
- Is it present?
- Is it in the right place?
- Does it have correct attributes?
Step 5: Verify Interactions (if applicable)
If the task involves behavior:
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.
- 7d ago First seen · 223 lines · 63 tokens per session scan A 033f9dccfdb4
yokay-browser-verifier is an agent published in the GitHub repository srstomp/pokayokay (9 stars, last pushed 2mo ago), licensed MIT. It adds 63 tokens to every session and 1,248 once invoked, about $0.0003 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
website-cloner
Pixel-perfect website cloning specialist using Chrome MCP - 5-phase pipeline from screenshot reconnaissance to visual QA, git worktree isolation, parallel builders.
08-visual-verify
Open daily HTML schedule in Chrome, screenshot it, and verify layout correctness.
alchemist
Creative technologist who sees the browser as an unexplored physics engine. Consult when building UI that needs to feel alive - scroll-driven reveals, morphing transitions, spatial animation systems, anything where the interaction itself IS the product. Thinks in weight, tension, and breath before thinking in code.…
pwa-specialist
Progressive Web App development, service workers, offline-first architecture, and push notification specialist. Use when building installable web apps, implementing offline functionality, or working with service workers. Trigger phrases: PWA, service worker, Web App Manifest, offline-first, push notification…
browser-extension-developer
Chrome, Firefox, and cross-browser extension development specialist. Manifest V3, service workers, content scripts, and WebExtension APIs. Use when building browser extensions or migrating from MV2 to MV3. Trigger phrases: browser extension, Chrome extension, Firefox addon, Manifest V3, MV3, content script, service…
firefox-extension-dev
Hands-on developer that writes the code and reads MDN live when the bundled references fall short. TRIGGER WHEN: creating, debugging or publishing any Firefox extension, WebExtension or browser add-on, migrating Manifest V2 to V3, or fixing cross-browser compatibility.