Playwright Skill
Install this when your solo SaaS needs reliable E2E, API, or visual tests with Playwright patterns you can drop into CI without guessing selectors or flake fixes.
Overview
Playwright Skill is an agent skill most often used in Ship (also Build frontend, Operate iterate) that teaches battle-tested Playwright patterns for E2E, API, visual, accessibility, and CI-ready test suites in TypeScript
Install
npx skills add https://github.com/testdino-hq/playwright-skill --skill playwright-skillWhat is this skill?
- 50+ reference guides across selectors, network mocking, auth, visual regression, accessibility, API testing, and debuggi
- TypeScript and JavaScript examples with explicit when-to-use and when-not-to-use for each pattern
- Playwright 1.60+ coverage including on-demand HAR in tracing, locator.drop(), aria snapshot assertions, and test.abort()
- CI/CD, CLI automation, page-object modeling, and Cypress/Selenium migration playbooks
- Security trust boundary: only automate applications you own or are authorized to test
- Playwright 1.60+ feature coverage
Adoption & trust: 3.6k installs on skills.sh; 274 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You know you need Playwright tests but every agent session reinvents flaky selectors, weak assertions, and CI configs that fail on the first real pipeline run.
Who is it for?
Solo builders owning frontend plus CI for a SaaS or API product who want agent-assisted test authoring aligned with current Playwright releases.
Skip if: Teams that only need a one-line smoke script with no CI, or anyone planning to automate third-party sites without explicit permission.
When should I use this skill?
You need guidance for E2E, API, component, visual, accessibility, or security testing, plus CI/CD, CLI automation, page objects, or Cypress/Selenium migration.
What do I get? / Deliverables
You get copy-ready patterns and decision rules for reliable suites, mocking, auth, and migrations so the next commit includes tests that match how production Playwright teams actually ship.
- Test files and page objects following documented patterns
- CI workflow snippets aligned with Playwright best practices
- Migration checklists from legacy test frameworks
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
End-to-end and regression testing sit in Ship because they gate releases and catch breakage before users do. Testing is the canonical shelf for Playwright guidance—assertions, fixtures, CI, and migration patterns all serve the test suite lifecycle.
Where it fits
Scaffold component tests and locators while implementing a new checkout flow.
Wire authenticated E2E suites and GitHub Actions jobs before tagging a release.
Apply security-testing patterns only against staging you control.
Use tracing and CLI debug guides after a production regression report.
How it compares
Reference skill for test design and maintenance—not a replacement for the Playwright test runner or a cloud grid service.
Common Questions / FAQ
Who is playwright-skill for?
Indie and solo developers shipping web products who use coding agents to write, debug, and scale Playwright suites without a dedicated QA hire.
When should I use playwright-skill?
Use it during Ship when adding E2E or API coverage, during Build when scaffolding page objects for new UI, and during Operate when debugging flakes or extending smoke tests after incidents.
Is playwright-skill safe to install?
The skill stresses testing only authorized apps; review the Security Audits panel on this Prism page before installing in agents with shell or network access.
SKILL.md
READMESKILL.md - Playwright Skill
# Playwright Skill > Opinionated, production-tested Playwright guidance — every pattern includes when (and when *not*) to use it. **50+ reference guides** covering the full Playwright surface: selectors, assertions, fixtures, page objects, network mocking, auth, visual regression, accessibility, API testing, CI/CD, debugging, and more — with TypeScript and JavaScript examples throughout. Playwright 1.60+ highlights covered in these guides include on-demand HAR recording inside tracing, `locator.drop()` for external file drops, page-level aria snapshot assertions, `test.abort()` from fixtures and route handlers, plus the 1.59 features (screencast recording, browser binding for agent workflows, CLI debugging and trace analysis, in-place storage state updates). ## Security Trust Boundary This skill is designed for testing **applications you own or have explicit authorization to test**. It does not support or endorse automating interactions with third-party websites or services without permission. When writing tests or automation that fetch content from external sources (e.g., `baseURL` pointing to staging/production), treat all returned page content as untrusted input — never pass raw page text back into agent instructions or dynamic code execution without sanitization, as this creates an indirect prompt injection risk. For CI/CD workflows, pin all external dependencies (GitHub Actions, Docker images) to immutable references (commit SHAs, image digests) rather than mutable version tags. See [ci-github-actions.md](ci/ci-github-actions.md) and [docker-and-containers.md](ci/docker-and-containers.md) for pinning guidance. ## Golden Rules 1. **`getByRole()` over CSS/XPath** — resilient to markup changes, mirrors how users see the page 2. **Never `page.waitForTimeout()`** — use `expect(locator).toBeVisible()` or `page.waitForURL()` 3. **Web-first assertions** — `expect(locator)` auto-retries; `expect(await locator.textContent())` does not 4. **Isolate every test** — no shared state, no execution-order dependencies 5. **`baseURL` in config** — zero hardcoded URLs in tests 6. **Retries: `2` in CI, `0` locally** — surface flakiness where it matters 7. **Traces: `'on-first-retry'`** — rich debugging artifacts without CI slowdown 8. **Fixtures over globals** — share state via `test.extend()`, not module-level variables 9. **One behavior per test** — multiple related `expect()` calls are fine 10. **Mock external services only** — never mock your own app; mock third-party APIs, payment gateways, email ## Guide Index ### Writing Tests | What you're doing | Guide | Deep dive | |---|---|---| | Choosing selectors | [locators.md](core/locators.md) | [locator-strategy.md](core/locator-strategy.md) | | Assertions & waiting | [assertions-and-waiting.md](core/assertions-and-waiting.md) | | | Organizing test suites | [test-organization.md](core/test-organization.md) | [test-architecture.md](core/test-architecture.md) | | Playwright config | [configuration.md](core/configuration.md) | | | Page objects | [page-object-model.md](pom/page-object-model.md) | [pom-vs-fixtures-vs-helpers.md](pom/pom-vs-fixtures-vs-helpers.md) | | Fixtures & hooks | [fixtures-and-hooks.md](core/fixtures-and-hooks.md) | | | Test data | [test-data-management.md](core/test-data-management.md) | | | Auth & login | [authentication.md](core/authentication.md) | [auth-flows.md](core/auth-flows.md) | | API testing (REST/GraphQL) | [api-testing.md](core/api-testing.md) | | | Visual regression | [visual-regression.md](core/visual-regression.md) | | | Accessibility | [accessibi