About this skill

Problem Solved

Automating local web apps is often slowed by scattered server startup parameters, needing front-end and back-end processes at the same time, and brittle selectors caused by dynamic DOM changes. This skill focuses on local Playwright scripts and treats scripts/with_server.py as a black box to manage single or multiple server lifecycles, reducing duplicated process-handling logic.

How It Works and Where to Stop

The workflow is “inspect first, then act”: render the page, inspect the DOM, derive selectors such as text=, role=, CSS, or ID, and then perform clicks, inputs, or assertions. For dynamic apps, wait for page.wait_for_load_state('networkidle') before checking the DOM. Scripts usually use sync_playwright(), close the browser when done, and rely on explicit waits like page.wait_for_selector() to reduce race conditions.

Note: do not read large bundled scripts to guess usage; run --help first and only inspect source when customization is truly needed. This skill fits local pages, static HTML, and front-end/back-end integration scenarios covered by Playwright. It is not a substitute for backend unit tests, load testing, or security testing.

Screenshots

Use Cases

Start local front-end and back-end services during integration, then verify login and key flows with Playwright
Inspect page buttons, links, and inputs, derive usable selectors, then run automation steps
Automate local static HTML pages, capture console logs, and locate front-end errors or script issues
Write synchronous Playwright scripts, wait explicitly for selectors, then submit forms and assert results

Best For

Front-end integration engineers: need to run local front-end and back-end services and verify key flows
Playwright script engineers: need to derive stable DOM selectors and reduce race conditions
Static page engineers: need to open local HTML, capture console logs, and reproduce issues
End-to-end QA engineers: need synchronous scripts to wait for elements before submitting and asserting