generate-playwright-tests

Generates Playwright end-to-end specs with MCP-derived accessibility-tree locators and two-layer assertions.

Updated Aug 1, 2026
One-click install
npx skills add https://github.com/dxiiren/project-skeleton --skill generate-playwright-tests-dxiiren
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: generate-playwright-tests
Source: https://github.com/dxiiren/project-skeleton/tree/main/.claude/skills-optional/generate-playwright-tests
Command: npx skills add https://github.com/dxiiren/project-skeleton --skill generate-playwright-tests-dxiiren

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Writing Playwright tests by hand often produces brittle specs with guessed CSS selectors, fixed sleeps, and assertions that pass without verifying real behavior. This Skill enforces a disciplined authoring workflow that derives stable locators from the live accessibility tree and requires every test to verify actual application state before claiming success. ## Core Features & Use Cases - MCP-Derived Locators: Drives a real browser through the Playwright MCP (browser_snapshot, browser_generate_locator) to produce stable role/label/text locators instead of brittle CSS selectors. - Two-Layer Assertion Rules: Enforces paired state-layer and visible-layer assertions for every stateful action, banning false-green patterns like waitForTimeout, networkidle waits, and OR'd success branches. - Run-and-Paste Verification: Requires executing the spec against a live server and pasting the pass/fail summary before any completion claim. - Use Case: A developer asks to write e2e tests for a checkout page; the Skill navigates the live app via the Playwright MCP, derives role-based locators for the form fields, authors a spec asserting both the URL change and rendered confirmation, runs it, and reports the result. ## Quick Start Ask the AI to generate Playwright e2e tests for a specific page or user flow in this project.

Frequently Asked Questions about generate-playwright-tests

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I generate Playwright e2e tests for a web page?

Start the dev server, navigate to the page via the Playwright MCP, take an accessibility snapshot, and derive role-based locators with browser_generate_locator. Then author the spec with two-layer assertions and run it against the live server before claiming it works.

How to write stable Playwright locators that don't break?

Use role, label, and text locators derived from the live accessibility tree rather than hand-written CSS selectors. The Playwright MCP's browser_generate_locator tool produces stable locators from the actual rendered page, falling back to ids or classes only when semantically unique.

Why are my Playwright tests flaky and how do I fix them?

Flakiness usually comes from fixed sleeps like waitForTimeout, networkidle waits on hydrating apps, or one-shot isVisible checks. Replace them with web-first auto-retrying assertions such as await expect(locator).toBeVisible() that wait for the actual condition.

Does this require the Playwright MCP server to be configured?

Yes, the Playwright MCP is mandatory because locators are derived from the live browser's accessibility tree. If it is not configured, the workflow stops and instructs you to run the MCP setup command rather than guessing selectors from memory.

What assertions should a Playwright test include after a user action?

Every stateful action needs two layers: a state assertion such as a URL change or response status, plus a visible-layer assertion on rendered UI. A lone toBeVisible check after a click is banned because the element was likely already visible.