playwright-e2e

Write stable Playwright browser tests for critical user journeys with page objects and deterministic fixtures.

Updated Jun 8, 2026
One-click install
npx skills add https://github.com/vovanostm-public/multica --skill playwright-e2e-vovanostm-public
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: playwright-e2e
Source: https://github.com/vovanostm-public/multica/tree/main/workflow-bundles/multica-specops-v5/codex_skills/.agents/skills/playwright-e2e
Command: npx skills add https://github.com/vovanostm-public/multica --skill playwright-e2e-vovanostm-public

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? End-to-end browser tests often become flaky, slow, and hard to maintain because they rely on brittle selectors, arbitrary sleeps, and non-deterministic data. This Skill provides a disciplined procedure for writing stable Playwright E2E tests that verify real user-visible behavior, including issue workflow states and human-in-the-loop blocker paths. ## Core Features & Use Cases - Stable Test Authoring: Enforces page objects, role/label/testid selectors, and explicit UI/event conditions instead of arbitrary waits. - Deterministic Setup: Guides creation of seeded fixtures so issue and workflow states are reproducible across runs. - Human-Loop Verification: Tests answer paths and blocked/unblocked states when human input gates a workflow. - Use Case: When a new issue workflow cockpit ships, use this Skill to write an E2E test that seeds an issue, walks the critical user path, and asserts the user-visible blocked and unblocked states with retained failure screenshots and traces. ## Quick Start Write a Playwright E2E test for the issue assignment flow using page objects, seeded fixtures, and assertions on the visible blocked and unblocked states.

Frequently Asked Questions about playwright-e2e

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

FAQPage Schema
How do I write stable Playwright E2E tests?▼

Use page objects for repeated operations, prefer role, label, or testid selectors that reflect UX intent, and create deterministic test data. Replace arbitrary sleeps with explicit UI or event conditions to eliminate flakiness.

How to test a human-in-the-loop workflow with Playwright?▼

Seed the workflow into a blocked state with fixtures, then drive the answer path through the UI and assert both the blocked and unblocked user-visible states. Keep artifacts and questions visible so the human-loop transition is verifiable.

When should I use E2E tests instead of component tests?▼

Use E2E tests when the flow needs full issue or workflow state with seeded fixtures across pages. If the behavior is pure component logic, a React Testing Library or unit test is the better choice.

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

Flakiness usually comes from arbitrary sleeps, brittle CSS selectors, and non-deterministic data. Replace sleeps with explicit event conditions, switch to role or testid selectors, and seed fixtures so every run starts from the same state.

What artifacts should a browser verification test retain?▼

Retain failure screenshots and traces for every run so regressions visible to users can be diagnosed. Outputs should also include typed evidence such as the browser verification plan, results, assumptions, and blockers.