Skip to content
Back to skills

Browser E2e

ASecurity

Verify a deployed UI in a browser for interaction, mobile layout, and visuals.

  • 25 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added October 18, 2026
ai-agentsapi

Works with

  • claude code
  • cli
  • api
  • mcp

Security analysis

A100/100

Scanned October 18, 2026

npx -y skills add nikolanovoselec/codeflare --skill browser-e2e --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Browser E2e?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Browser E2e
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/nikolanovoselec-browser-e2e-codeflare/badge)](https://www.skillsdirectory.com/skills/nikolanovoselec-browser-e2e-codeflare)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: browser-e2e
description: Verify a deployed UI in a browser for interaction, mobile layout, and visuals.
---

# Browser e2e (Pi)

Verify your **own** deployed app the way a person would: open it in a real browser, interact with it, look at what actually rendered, and judge whether it satisfies the requirement — instead of asserting on brittle selectors. Backed by Cloudflare Browser Run (headless Chrome) through the **`chrome-devtools`** server, which Pi reaches via the **`mcp` proxy** (the `pi-mcp-adapter`). Pi has full parity with Claude Code here — same interactive toolset.

This is the **semantic** half of e2e. A scripted test in CI proves a fixed invariant (`expect(price).toBe('$9')`) and breaks when the copy changes; this proves *"does the thing actually work and look right?"* and survives wording/layout changes. Use both: deterministic invariants belong in CI; judgment ("the login flows seamlessly from the landing", "this caption is clipped mid-word on mobile", "the empty state reads wrong") belongs here.

Only available in Pro (advanced) sessions with a Cloudflare API token carrying the **Browser Rendering – Edit** scope. If the `mcp` proxy can't reach a `chrome-devtools` server, browser e2e is not enabled — you can still do a **read-only** check with the native `browser_markdown` (judge rendered content/structure), but you cannot drive a flow; otherwise fall back to reasoning over the code and CI.

## Two depths — pick by what the acceptance criterion needs

- **Read-only state check** (cheap): the AC is about *rendered content/structure* (right copy, expected elements, a URL-reachable state like `?status=requested`). Use native `browser_markdown` / `browser_scrape` — no live session. Don't open chrome-devtools for this.
- **Interactive flow / visual** (chrome-devtools): the AC needs *clicking through steps*, *a screenshot*, or a *specific viewport*. Use the chrome-devtools tools via the proxy.

## How to use (interactive, via the `mcp` proxy)

Drive the `chrome-devtools` server's tools through the adapter `mcp` proxy (see the `pi-mcp-adapter` skill for proxy mechanics — list the server's tools, then call them):

1. `resize_page` to a mobile viewport (e.g. `390 x 844`) — or `emulate` — when verifying responsive behavior. **Check mobile first.**
2. `navigate_page` to the deployed URL. For JS-heavy pages, let it settle (wait for network idle) before reading.
3. `take_snapshot` to read the rendered accessibility tree, or `evaluate_script` to pull concrete facts from the live DOM (computed styles, element counts, `scrollWidth > clientWidth` for overflow, an image's `naturalWidth` to confirm it loaded).
4. `take_screenshot` to judge anything visual — layout, spacing, clipping, on-brand feel.
5. `click` / `fill` to walk a flow, re-observing after each step.
6. **Judge against the requirement and report a verdict**: pass/fail per acceptance criterion, each backed by what you observed (a screenshot, a measured value, the rendered text) — not "the selector existed".

Example task: *"e2e test the integration deployment from a mobile device viewport"* → `resize_page` to 390×844 → `navigate_page` → `take_snapshot` + `take_screenshot` → walk the sign-in / contact flow with `click`/`fill` → verdict per AC, with screenshots.

## Targets

- **Public / deployed URLs only.** Browser Run is remote (Cloudflare's edge), so it **cannot reach `localhost`, private IPs, or container-internal ports** — point it at the deployed preview/integration URL, not a local dev server.
- Your **own** application under test (or a target you're authorized to drive). This is not for crawling third-party sites — that's the `browser-run` fetch fallback.
- Prefer non-destructive paths. If a flow mutates state, use disposable/test data and say so.

## Notes

- Extract just what you need (snapshot/evaluate/targeted screenshot) rather than dumping whole pages, to protect the context window.
- The verdict is the deliverable. "Looks fine" is not a verdict; "AC2 fails: on a 390px viewport the foot caption is clipped after 'corrected, an…' — screenshot attached" is.
- Findings you confirm here are real findings — fix them (or file them), don't just note them.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.