Playwright prompts work best when they describe an outcome a person can observe: an order appears, an upload finishes, or a rejected login leaves the form usable. Give the agent a working test from your repository before asking it to add coverage. The prompts below address three different jobs: building a journey, diagnosing an intermittent failure, and checking isolation. They are intended for a repository-aware agent or a chat supplied with the relevant files.
Prepare a reproducible browser task
Record the application URL, browser project, authentication setup and test command. Describe whether the test owns its data or shares fixtures with other tests. Include a screenshot only when appearance matters; a trace is more useful for understanding timing. Replace each double-braced blank before running a prompt. If the agent cannot open the app, ask it to list assumptions and produce a proposed test without claiming execution.
Playwright's best practices recommend testing visible behavior and keeping tests independent. Those principles inform this collection; the prompts and review sequence are original workflow suggestions.
Generate a test around one completed journey
A test plan should say what counts as success before selecting elements. For a checkout flow, reaching the payment page is a different assertion from creating exactly one order. Ask for the latter only when a controlled payment environment exists. Keep the initial test small enough that its failure identifies a useful boundary.
Add a Playwright test for {{journey}} in {{test_directory}}.
Read our config and {{example_test}} first. List the setup, user actions
and visible success condition before editing. Use stable locators that
match the rendered interface. Own the test data and clean it up.
Cover the success path and {{failure_case}}. Run the relevant project
with our existing command. Report the exact command and observed result;
if execution is blocked, say what remains unverified.
Diagnose a flaky failure from evidence
A retry that passes does not explain an earlier failure. Provide both a failed attempt and a passing attempt when available. Ask the agent to distinguish application latency, a mistaken locator, leaked state and an unavailable dependency. This stops a timeout increase from becoming the default repair for unrelated problems.
Investigate this intermittent Playwright failure: {{failure_output}}.
Use {{trace_path}}, {{test_path}} and {{application_code}}.
Build a short evidence table: observation, possible cause, next check.
Find the readiness condition the test should observe. Propose the smallest
repair, with no arbitrary sleep. Run the test repeatedly in the failing
browser project and explain what that run does and does not establish.
Check parallel runs and authentication boundaries
Shared accounts can make individually correct tests interfere with each other. Review the identifiers created during setup, the storage state being reused and what logout changes. Include two users if ownership matters. A useful isolation review explains how one worker could invalidate another worker's data, rather than merely suggesting parallel execution be disabled.
Review {{test_directory}} for parallel-run interference.
Trace shared accounts, storage state, mutable fixtures and reused IDs.
For each concrete conflict, show the competing actions and suggest a
per-test or per-worker boundary. Add one regression that demonstrates
{{reported_isolation_bug}}. Preserve legitimate authentication reuse.
Decide whether the test earns its maintenance cost
Read the new test without reading the component implementation. Its name and assertions should explain a user-visible contract. Confirm that it fails when the relevant behavior breaks, and that a cosmetic class change alone does not invalidate the result. Review teardown failures as carefully as setup failures: abandoned records can create tomorrow's intermittent bug.
Save the version that works in Kipt with blanks for journey, test directory and failure evidence. Keep traces beside the issue or build artifact, rather than embedding sensitive session data in a reusable prompt. For lower-level interaction coverage, continue with the Testing Library prompts.