Playwright Test Automation Assistant

Problem Solved

Playwright tests often become brittle in real projects: page.waitForTimeout(), raw CSS/XPath, shared state between tests, and local passes that miss cloud device combinations. This skill breaks the request into explicit decisions: local or cloud execution, target language, and whether the output should be a one-off script or a full test suite, so generated tests are easier to maintain.

How It Works

It works in three steps:
- Execution target: default to local when cloud, real devices, or cross-browser needs are not mentioned; route to cloud or specialized capabilities when signals like TestMu, LambdaTest, or HyperExecute appear.
- Language detection: default to TypeScript, with JavaScript, Python, Java, and C# patterns available by language.
- Scope selection: one-off scripts produce a standalone file; existing projects follow current conventions; new suites use scaffolding; flaky tests enter a debugging checklist.
Core practices emphasize Web-First assertions and selector priority: prefer getByRole(), getByLabel(), getByPlaceholder(), and getByText(), using getByTestId() only as a fallback. For projects with more than three tests, POM is recommended, with patterns for auth reuse, network mocking, visual regression, mobile testing, API testing, and CI sharding.

Boundary

Best for front-end or full-stack teams that need E2E test automation. When the focus is large-scale parallelism, dedicated visual regression, or real mobile devices, the skill points to the relevant references or specialized skills instead of forcing every case into local scripts.