Playwright Agent Rules

Browser automation and end-to-end testing for Chromium, Firefox, and WebKit.

Overview

Playwright's CLAUDE.md maps the monorepo and its test fixtures, then states the boundaries contributors must preserve. Local guides cover deeper implementation work, while one flint command runs code generation, linting, and type checks together.

Verification by change type Hard prohibitions Pointing at the source of truth Contribution etiquette Router files

Documents

├── 
└── .claude
    └── skills
        └── playwright-dev
            ├── 
            ├── 
            ├── 
            └──

Techniques in this file

01 / Verification by change type

Choose the suite by the fixtures a test needs

The guide distinguishes page-and-server tests from browser, browser-type, and context lifecycle tests. Its decision rule maps those needs to separate directories and fixture imports.

84**Decision rule**: Does the test need `browser`/`browserType`/`context` → `tests/library/`. Just needs `page` + `server` → `tests/page/`.

02 / Hard prohibitions

Enforce the client/server boundary through declarations

Client and server code communicate only through the protocol. Creating or moving files requires updating the relevant DEPS.list, and strict lists allow only declared imports.

90**Key rule**: Client code NEVER imports server code. Server code NEVER imports client code. Communication is only through the protocol.91When creating or moving files, update the relevant `DEPS.list` to declare allowed imports. Files marked `"strict"` can only import what is explicitly listed.

03 / Pointing at the source of truth

Point verification at the integrated check

The flint command includes types, documentation checks, dependency checks, and generators. The guide explicitly requires it before committing instead of isolated lint or type-check commands.

53**Always run `flint` before committing.** Do not use `tsc --noEmit` or individual lint commands separately.

04 / Contribution etiquette

Explain incremental review history

The guide defaults to new commits for follow-up changes because amending rewrites the review trail and forces a force-push. It separately requires explicit user direction before pushing.

153**Never amend commits.** Always create a new commit for follow-up changes, even when iterating on an open PR. Amending rewrites history and forces a force-push, losing the incremental review trail. Only amend if the user explicitly says so.

05 / Router files

Route implementation tasks into local development guides

The final index maps architecture, API changes, tools and CLI commands, and vendoring to individual documents. Each link describes the workflow and concepts covered.

Source excerpt starting at line 159.
159Detailed guides for common development tasks:

Ideas for your repo

Choose test locations from their required fixtures and behavior.
Enforce architectural import boundaries with machine-readable declarations.
Use the project’s integrated verification command when it includes generation.
Keep follow-up commits reviewable and make publishing authorization explicit.