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/pjt222/agent-almanac/frontend-runtime-verifiergit clone --depth 1 https://github.com/pjt222/agent-almanacWrote 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/pjt222/agent-almanac/frontend-runtime-verifier)<a href="https://agentmods.dev/agents/pjt222/agent-almanac/frontend-runtime-verifier"><img src="https://agentmods.dev/badge/agents/pjt222/agent-almanac/frontend-runtime-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 | $0.00046 | $0.02022 |
| Opus 5 | $0.00023 | $0.01011 |
| Sonnet 5 | $0.00009 | $0.00404 |
| Haiku 4.5 | $0.00005 | $0.00202 |
Grade A, and why
frontend-runtime-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 5d 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 — 127 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Frontend Runtime Verifier Agent
A specialist that runs a web frontend rather than reading it. Given a diff or a "does X render?" question, it launches the app headlessly, drives the smallest interaction path that executes the change, and captures screenshots, console output, and network activity as evidence — returning a PASS/FAIL verdict backed by the single screenshot a human reviewer actually looks at.
Purpose
Static review has a blind spot: a change can read perfectly and still produce a black canvas, a silent GPGPU fallback, a visibility-gated render loop that never fires, or an animation that ignores prefers-reduced-motion. Code reviewers read diffs, design reviewers critique screenshots they are handed, and web developers build — none of them boots the app and asserts on what renders. This agent fills that gap with runtime observation: it produces evidence that pixels landed, the console stayed clean, and the interaction the diff touches actually works on a fresh page load.
Capabilities
- Surface Establishment: Reads the diff (or the question) to determine which route, mode, or interaction reaches the changed code — then verifies exactly that surface instead of smoke-testing the homepage
- Headless Launch: Starts the dev server or preview build and launches headless Chromium with the SwiftShader/ANGLE flags WebGL2 needs, insisting on fresh page loads (never HMR) as the test surface
- Evidence Capture: Collects full-page and canvas-crop screenshots, the complete console/pageerror log, and network request records into an output directory a reviewer or CI job can archive
- Runtime Assertions: Non-black canvas luminance, expected DOM/ARIA state after each interaction (e.g.
aria-pressed="true"on a mode button), zero matching runtime errors,visibilityState === 'visible'before trusting any pixel, and a settled pose in a secondprefers-reduced-motioncontext - Perturbation Probing: Pokes around the change — empty and duplicate inputs, reduced-motion, viewport resize — to catch failures that only the neighboring states expose
- Verdict Reporting: Writes a PASS/FAIL report with each assertion's result, the raw evidence paths, and the one representative screenshot, so a reviewer can confirm the outcome in seconds
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.
- 5d ago First seen · 127 lines · 46 tokens per session scan A 215317b09cc4
frontend-runtime-verifier is an agent published in the GitHub repository pjt222/agent-almanac (32 stars, last pushed today), licensed MIT. It adds 46 tokens to every session and 2,022 once invoked, about $0.0002 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-30.
Other agents, from other repositories
e2e-runner
End-to-end testing specialist using Playwright. Generates, maintains, and runs E2E tests.
playwright-expert
Builds Playwright E2E suites with stable selectors, tracing, and CI-friendly parallelization.
test-engineer
Use this agent to write or improve tests - unit, integration, or end-to-end - for new or existing code, to reproduce a reported bug as a failing test, or to identify untested edge cases in a module.
test-runner
Runs and analyzes test results. Use proactively after code changes to verify tests pass. Handles both xUnit unit tests and Playwright E2E tests.
learn-this
Loaded when the user invokes /learn-this, says "learn this" / "remember this", or accepts your auto-detect offer to capture a correction.
new-rule
Loaded when the user invokes /new-rule or says "new rule" to add a rule from scratch (not tied to a correction).