browser-automation

description	Browser automation for rendered UI exploration, validation, screenshots, recordings, and end-to-end flows. Use when a task needs an actual browser or rendered DOM: inspect UI state, click/fill forms, debug frontend behavior, capture evidence, verify a feature, or run/generate browser tests. NOT for API checks or pure logic tests where curl, unit tests, or JSDOM is cheaper.
name	browser-automation

Browser Automation

Use a real browser only when rendered behavior matters: UI state, navigation, forms, auth, screenshots, recordings, accessibility, visual checks, or end-to-end flows.

Keep automation temporary unless the user asks for permanent tests. Do not use a browser for plain HTTP API checks or pure logic tests.

Runtime Selection

1. Prefer a platform built-in browser tool when available in the active tool list. See references/platform-browser-tools.md.
2. Use the project's configured browser runner when it exists.
3. Use playwright-skill only as the bundled fallback/runtime reference.
4. If no runtime is available, report blocked with the missing tool/package.

Use the cheapest runtime that proves the claim.

Workflow

1. Define the goal: explore, validate, screenshot, record, debug, or test.
2. Read needed local context: start scripts, browser config, routes, fixtures, seed/reset docs, and auth notes.
3. Detect or start the dev server. Reuse a reachable server.
4. Use deterministic data: seeded users, fixed dates, stable IDs, reset state, and mocked external services.
5. Drive with semantic targets first: role, label, text, test id; CSS last.
6. Capture artifacts needed to support the result: screenshot, trace, console errors, network failures, accessibility snapshot, manifest, or report.
7. Prefer screenshot/manifest evidence for visual checks in headless harnesses.