跳到主要内容

Browser E2E

Browser smoke and E2E recipes using agent-browser tools.

Skill metadata​

SourceBundled (installed by default)
Pathskills/web-development/browser-e2e
Version1.1.0
AuthorVibeOS
LicenseMIT
Platformslinux, macos, windows
Tagsbrowser, e2e, playwright, smoke, health, qa
Related skillsinternet-starter, deploy-presets, browser-network-assert, ship-web-service

Reference: full SKILL.md​

信息

The following is the complete skill definition that VibeOS loads when this skill is triggered. This is what the agent sees as instructions when the skill is active.

Browser E2E Recipes

Repeatable smoke checks for local or deployed web apps using built-in browser tools (browser_navigate, snapshot, click, type). Not a replacement for full Playwright test suites — a fast agent-driven checklist.

When to Use​

  • After scaffolding or deploying a starter
  • User asks to "click through" login, form, or checkout
  • Verify / and health endpoints in a real browser

Prerequisites​

  • Browser toolset available (agent-browser / local Chrome)
  • Target URL reachable (local localhost or remote)
  • Prefer vibeos project servers --expect <port> --health before opening the browser

How to Run​

Minimal smoke for an internet-starter:

  1. browser_navigate → app URL (e.g. http://127.0.0.1:3000).
  2. Snapshot; confirm title/heading visible.
  3. browser_navigate → /api/health or /health; confirm ok in page text.
  4. Network assert (status contracts): run skill browser-network-assert (assert_network.py --probe … --require-ok /health).
  5. Optional: click primary CTA; snapshot again.

For forms:

  1. Navigate to the form page.
  2. Snapshot; fill fields with browser_type using refs.
  3. Submit; snapshot; assert success text or redirect.

Quick Reference​

CheckExpect
HomeRenders without console fatal errors
HealthJSON or text contains ok/healthy
Networkassert_network.py exits 0 (no unexpected 5xx)
FormSuccess state after submit

Procedure​

  1. Confirm the server is up (vibeos project servers / curl health) before opening the browser.
  2. Keep journeys short (≤8 steps); stop on first hard failure.
  3. Report: URL, steps taken, pass/fail, screenshot path if captured.
  4. Do not store passwords in skills or plans — use env/secrets.

Pitfalls​

  • Prefer refs from the latest snapshot; stale refs fail.
  • Auth walls: ask the user; do not brute-force.
  • Heavy SPAs may need a short wait after navigate before snapshot.
  • Do not rely on CDP Network event subscriptions across tool calls — use browser-network-assert probes/HAR instead.

Verification​

  • Home snapshot shows expected brand/heading.
  • Health check returns success.
  • assert_network.py report "ok": true.
  • Optional journey ends on a success marker the user named.