Playwright Dev
Navigate the Playwright monorepo to add APIs, MCP tools, CLI commands, vendor bundles, and dashboard UI as a framework contributor.
Overview
Playwright Dev is an agent skill for the Build phase that explains how to develop Playwright—APIs, MCP tools, CLI commands, vendor deps, and dashboard UI in the monorepo.
Install
npx skills add https://github.com/microsoft/playwright --skill playwright-devWhat is this skill?
- Points to CLAUDE.md for monorepo build, test, lint, and coding conventions
- Library architecture guide for client/server/dispatcher and DEPS rules
- API workflow: define docs, implement client/server, add tests
- MCP tools and CLI commands plus vendor bundling (utilsBundle, coreBundle, babelBundle)
- WebKit Safari BROWSER_VERSION constant location and bisect-published-versions regression workflow
- WebKit Safari version is set via BROWSER_VERSION in packages/playwright-core/src/server/webkit/wkBrowser.ts
- Documented bundle surfaces include utilsBundle, coreBundle, and babelBundle
Adoption & trust: 2.1k installs on skills.sh; 90.5k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You need to change Playwright's APIs, MCP tools, or CLI but the monorepo layout, DEPS rules, and test expectations are unclear.
Who is it for?
Solo maintainers or indie teams contributing patches, MCP extensions, or CLI features directly in the Playwright source tree.
Skip if: Builders who only need to write Playwright tests against their own app without modifying the framework.
When should I use this skill?
Developing Playwright—adding APIs, MCP tools, CLI commands, vendor dependencies, or dashboard changes in the upstream repo.
What do I get? / Deliverables
You follow the documented paths to implement client/server changes, tooling, and bundles with the repo's build, lint, and test conventions.
- Implemented API or tool changes following library and tools guides
- Tests and DEPS hygiene aligned with monorepo conventions
- Documented CLI or MCP additions ready for upstream review
Recommended Skills
Journey fit
Contributing to Playwright itself is deep build-time engineering for agent and browser automation infrastructure, not shipping your app's launch copy. Agent-tooling fits skills that extend MCP surfaces, CLI commands, and protocol layers inside an automation framework repo.
How it compares
Meta contributor guide for the Playwright repo, not a skill that generates test specs for your SaaS.
Common Questions / FAQ
Who is playwright-dev for?
It is for developers modifying the Playwright framework—APIs, MCP integration, CLI, bundling, or dashboard—not for app teams running standard browser tests.
When should I use playwright-dev?
Use it in Build agent-tooling work when adding an MCP tool, CLI command, vendor package, WebKit user-agent update, or debugging regressions via bisect-published-versions.
Is playwright-dev safe to install?
It is documentation for development workflows; review the Security Audits panel on this page and follow upstream Microsoft Playwright contribution policies when cloning and building the repo.
SKILL.md
READMESKILL.md - Playwright Dev
# Playwright Development Guide See [CLAUDE.md](../../../CLAUDE.md) for monorepo structure, build/test/lint commands, and coding conventions. ## Detailed Guides - [Library Architecture](library.md) — client/server/dispatcher structure, protocol layer, DEPS rules - [Adding and Modifying APIs](api.md) — define API docs, implement client/server, add tests - [MCP Tools and CLI Commands](tools.md) — add MCP tools, CLI commands, config options - [Vendor Dependencies & Bundling](vendor.md) — utilsBundle, coreBundle, babelBundle; adding vendored npm packages; DEPS.list; `check_deps` - [Updating WebKit Safari Version](webkit-safari-version.md) — update the Safari version string in the WebKit user-agent - [Bisecting Across Published Versions](bisect-published-versions.md) — reproduce regressions side-by-side from npm and diff `node_modules/playwright/lib/` between versions - [Dashboard](dashboard.md) - the UI powering the "playwright cli show" command, and how to work on it # Updating WebKit Safari Version The Safari version string used in the WebKit user-agent is declared in one place: **[packages/playwright-core/src/server/webkit/wkBrowser.ts](../../../packages/playwright-core/src/server/webkit/wkBrowser.ts)** — `BROWSER_VERSION` constant (line ~35). ```ts const BROWSER_VERSION = '26.4'; const DEFAULT_USER_AGENT = `Mozilla/5.0 ... Version/${BROWSER_VERSION} Safari/605.1.15`; ``` ## Steps to update 1. **Find the latest stable Safari version** — search `site:developer.apple.com "Safari X.Y Release Notes"` or check the [Safari Release Notes](https://developer.apple.com/documentation/safari-release-notes) index. The highest numbered entry that is not a Technology Preview is the current stable release. 2. **Update `BROWSER_VERSION`** in `wkBrowser.ts`. 3. **Run lint** to update any generated files that embed the version: ```bash npm run flint ``` # Adding and Modifying APIs - Before performing the implementation, go over the steps to understand and plan the work ahead. It is important to follow the steps in order, as some of them are prerequisites for others. ## Step 1: Define API in Documentation Define (or update) API in `docs/src/api/class-xxx.md`. For the new methods, params and options use the version from package.json (without `-next`). ### Documentation Format **Method definition:** ```markdown ## async method: Page.methodName * since: v1.XX - returns: <[null]|[Response]> Description of the method. ### param: Page.methodName.paramName * since: v1.XX - `paramName` <[string]> Description of the parameter. ### option: Page.methodName.optionName * since: v1.XX - `optionName` <[string]> Description of the option. ``` **Key syntax rules:** - `* since: v1.XX` — always take the version from package.json (without -next) - `* langs: js, python` — language filter (optional) - `* langs: alias-java: navigate` — language-specific method name - `* deprecated: v1.XX` — deprecation marker - `<[TypeName]>` — type annotation: `<[string]>`, `<[int]>`, `<[float]>`, `<[boolean]>` - `<[null]|[Response]>` — union type - `<[Array]<[Locator]>>` — array type - `<[Object]>` with indented `- \`field\` <[type]>` — object type - `### param:` — required parameter - `### option:` — optional parameter - `= %%-placeholder-name-%%` — reuse shared param definition from `docs/src/api/params.md` **Property definition:** ```markdown ## property: Page.propName * since: v1.XX - type: <[string]> Description. ``` **Event definition:** ```markdown ## event: Page.eventName * since: v1.XX - argument: <[Dialog]> Description. ``` Keep methods, events and property definitions sorted alphabetically within the file. Watch will kick in and auto-generate: - `packages/playwright-core/types/types.d.ts` — public API types - `packages/playwright/types/test.d.ts` — test API types ## Step 2: Implement Client API