ui-test-playwright

Playwright UI Automation Testing

English version: see the matching English skill.

When to Use

When you need to produce a test plan or automation design for a Playwright UI automation testing workflow.
When the project already uses the relevant tools, or you want a tool-specific plan that can be directly implemented.

Use Markdown by default. Unless the request explicitly requires another format, do not extend the output format further.

Open prompts/ui-test-playwright.mdand use it as the main prompt.
Supplement with real project context: scope, environment, constraints, risks, dependencies, and expected deliverables.
If the input is incomplete, first return a usable first version and mark the missing information and assumptions.

When calibrating domain results, correct comparisons, or evidence gaps, read the desensitized input, item-by-item expectations, and recomputation basis of references/domain-decision-example.md .
prompts/ui-test-playwright.md: The main prompt for this skill.
references/framework-spec.md: Tool-specific structure and coverage description.
references/setup-and-ci.md: Installation, execution, and CI instructions.
examples/sample-context.md: Example request context.
scripts/run-tests.sh: Lightweight local execution entry point.

Pin the project's Playwright/Node/browser versions, projects/fixtures, and configuration; use the real entry points, record test IDs, commit, worker/project, and environment; for incompatible configurations, diagnose first rather than switching frameworks without authorization.
Prioritize stable semantic locators such as role/name/testid, and after execution use auto-retrying assertions to verify orders/accounting/status and the principal; page title/URL only satisfy the corresponding navigation obligation and cannot replace payment success.
Each worker must have an independent browser context, storage state/account, and business key; sharing conflicting data is prohibited; different contexts in the same browser must still verify server-side account isolation, and teardown must clean up in reverse dependency order.
Use erroneous business states and parallel A/B comparisons to verify assertion sensitivity; on failure retain trace/screenshot/logs and a non-zero runner/CI, and the first retry failure must still be visible. Report generated assets, actual browser runs, and business acceptance separately.

Do not directly give a generic plan when the scope is vague and context is lacking.
Do not treat all modules and scenarios as equally important.
Do not skip explaining assumptions and missing information.

Start from the prompt file and only supplement context that truly affects the result.
Keep the output risk-driven and directly usable for execution or review.
When information is incomplete, first provide a usable version, then clearly mark the gaps.
When verifying the business assertions, failure propagation, or isolation of generated assets, read evals/fixtures/checkout-app/README.md, and use local good/bug/timeout comparisons; execute only when the runtime is explicitly specified.