Skip to main content
rulesSource-backedReview first Safety · Privacy

Playwright Expert - CLAUDE.md Rules for Claude Code

Transform Claude into a Playwright specialist with deep knowledge of browser automation, resilient locators, fixtures, tracing, and CI-friendly end-to-end testing.

by jaso0n0818·added 2026-06-17·
HarnessClaude Code
Review first review before installing

Open the source and read safety notes before installing.

Privacy notes

  • Rules reference test credentials and environment URLs; store them in CI secrets or local env files, never in committed test sources.

Schema details

Install type
copy
Troubleshooting
No
Full copyable content
You are an expert Playwright developer focused on reliable browser automation.

## Locators

- Prefer role, label, and test-id locators over brittle CSS chains.
- Use auto-waiting assertions (`expect(locator).toBeVisible()`) instead of manual sleeps.

## Fixtures and isolation

- Keep tests independent; reset state in `beforeEach` or dedicated fixtures.
- Share authenticated contexts through fixtures rather than global mutable state.

## Debugging and CI

- Enable traces on first retry in CI and inspect failures with the trace viewer.
- Run headed locally only when debugging; keep CI headless and parallel-safe.

About this resource

Playwright Expert

Use these rules when writing or reviewing Playwright end-to-end tests.

Locator strategy

Prefer accessible locators (getByRole, getByLabel, getByTestId) and keep selectors stable across UI refactors. Avoid XPath unless no semantic locator exists.

Assertions and timing

Rely on Playwright auto-waiting and web-first assertions. Do not add arbitrary waitForTimeout calls when an assertion or locator state can express the condition.

Fixtures

Model login flows, API seeding, and shared browser contexts as fixtures. Keep each test able to run alone and in parallel without order dependence.

Tracing and CI

Capture traces and screenshots on failure, shard suites in CI, and pin browser versions to match the project's Playwright release.

References

Source citations

Add this badge to your README

Show that Playwright Expert - CLAUDE.md Rules for Claude Code is listed on HeyClaude. Paste this Markdown into your README — it renders the badge and links back to this page.

Listed on HeyClaude
[![Listed on HeyClaude](https://heyclau.de/badge/rules/playwright-expert.svg)](https://heyclau.de/entry/rules/playwright-expert)

How it compares

Playwright Expert - CLAUDE.md Rules for Claude Code side by side with its closest alternative on trust, install, platform support, and disclosed safety notes — all from reviewed registry metadata.

FieldPlaywright Expert - CLAUDE.md Rules for Claude Code

Transform Claude into a Playwright specialist with deep knowledge of browser automation, resilient locators, fixtures, tracing, and CI-friendly end-to-end testing.

Open dossier
AI-Generated Frontend Accessibility Review Rules

Source-backed rules for reviewing AI-generated frontend UI changes for accessibility before merge, with semantic HTML, keyboard paths, focus management, labels, automated scan limits, manual checks, and privacy-safe evidence.

Open dossier
Trust
Install riskReview firstReview first
Notes Safety · Privacy Safety Privacy
Categoryrulesrules
Sourcesource-backedsource-backed
Authorjaso0n0818MkDev11
Added2026-06-172026-06-04
Platforms
Claude Code
Claude Code
Source repo
Safety notes— missingAI-generated UI can silently replace semantic controls with divs, remove labels, hide focus indicators, break keyboard order, change error messaging, or add motion that affects users. Automated scans catch important classes of issues but do not prove that custom widgets, focus restoration, reading order, copy meaning, or assistive-technology behavior are correct. Browser automation and accessibility checks should run against local, preview, or staging environments with test accounts so forms, payments, messages, and destructive actions are not triggered in production.
Privacy notesRules reference test credentials and environment URLs; store them in CI secrets or local env files, never in committed test sources.Accessibility evidence can include screenshots, DOM text, accessible names, form values, labels, user content, network traces, browser storage, cookies, and test account data. Do not paste raw screenshots, traces, accessibility trees, DOM snapshots, customer names, private routes, or production form data into public PR comments without redaction. Use synthetic content and test accounts for accessibility examples, especially when reviewing auth, billing, dashboards, healthcare, education, or support flows.
Prerequisites— none listed
  • A frontend pull request, patch, generated component, route, story, or visual diff with enough context to identify changed user flows.
  • Access to the project's accessibility target, component library conventions, design tokens, browser test command, and review environment.
  • A local, preview, or staging URL where keyboard checks and automated accessibility scans can run without touching production data.
  • Permission to block merge when generated UI removes accessibility semantics or when verification evidence is incomplete.
Install
Config
Citations
ClaimUnclaimedUnclaimed

Signals

Loading live community signals…

More like this, weekly

A short, calm digest of reviewed Claude resources. Unsubscribe any time.