playwright-browser-automation

name	playwright-browser-automation
description	Use Playwright for browser automation, UI validation, E2E tests, and interaction debugging. Useful for flows that need real page navigation, assertions, screenshots, or request interception.
owner	any
trigger	null
version	2

Playwright Browser Automation

Use this when you need to validate browser behavior with real interactions instead of static reasoning.

Setup

If Playwright is not already present in the repo, install it before writing tests.

Locator Priority

1. getByRole, getByLabel, getByText, getByTitle, getByAltText
2. getByTestId
3. CSS selectors only as a last resort

References

• Read references/playwright-patterns.md when you need concrete examples for navigation, assertions, network interception, auth reuse, or local test commands.
• Keep the SKILL body focused on when to use Playwright and how to structure the work; keep the code snippets in the reference file.

Good Uses

• Task and dashboard interaction flows
• Regression checks for UI state transitions
• Request/response mocking for hard-to-reproduce states
• Screenshot-based checks when visual output matters
• Reproducing browser-only failures
• Phaser or canvas-based game flows where you must click the canvas or send keyboard input after load

Workflow

1. Reproduce the browser-facing problem with the smallest realistic flow.
2. Prefer resilient locators and user-visible assertions over DOM-coupled selectors.
3. Add request interception or stored auth only when the scenario needs it.
4. Keep tests focused on externally visible behavior, not implementation details.

Canvas And Game Note

If the app is canvas-driven, loading the page is not enough. Focus the canvas or visible start control, send at least one real input event, wait for the next rendered state, and record whether the game reacts without console or page errors.

Keep tests focused on user-visible behavior and resilient locators.