Use when you need to verify a frontend / gateway / end-to-end flow in a real browser instead of by hand - drive a containerized Chromium (Playwright over CDP) through the click path, capture console/network/screenshot…
---
name: browser-verify
description: Use when you need to verify a frontend / gateway / end-to-end flow in a real browser instead of by hand — drive a containerized Chromium (Playwright over CDP) through the click path, capture console/network/screenshots, correlate the frontend symptoms with backend logs by trace id, and report a pass/fail conclusion with evidence. Triggers like "verify X in the browser", "e2e check X", "click through the UI for X".
---
# browser-verify
Drive a real browser through a click path, capture what happened (console, network,
screenshots), correlate it with backend logs by trace id, and return a **pass/fail
conclusion** — not a pile of artifacts. The point is to verify behavior the way a
user experiences it, and to attribute any failure to a concrete layer (frontend,
network, or backend) with one line of evidence. **Don't ask a human to click the UI.**
The reference setup is a containerized Chromium exposing the Chrome DevTools Protocol
(CDP), with a persistent profile so login state survives, plus Playwright (via MCP or
a Python fallback) to drive it. It runs wherever you can reach the CDP endpoint;
[references/cold-start.md](references/cold-start.md) brings it up from scratch on any
Linux host with Docker.
## When to use
- Verify a frontend/gateway/routing flow actually works end to end after a change.
- Reproduce a "works in my browser / fails in prod" symptom under controlled capture.
- Attribute a slow or failing user action across frontend ↔ network ↔ backend.
… install to load the full skill