Cypress prompts are useful when they explain which transition a test needs to observe. An application may render a list before its latest response arrives, or display a success message before a background refresh finishes. Without a clear contract, an agent can make a flaky test pass locally by delaying everything. These prompts ask for controlled setup, meaningful assertions and evidence from the failing run.
Gather a spec and the conditions of failure
Include the spec file, Cypress configuration, package version and exact invocation. Describe whether the failure appears only in CI, only in a particular browser or only when another test runs first. Attach available screenshots, video and request evidence with sensitive details removed. Different symptoms require different repairs, so avoid summarizing every failure as a timing issue.
The Cypress best-practices guide covers independent tests, stable selectors and avoiding unnecessary waiting. This collection adds original prompts for applying those principles to a specific application rather than copying a generic spec.
Build one independently repeatable journey
Ask the agent to establish the state the journey needs and identify which record the test creates. A purchase, signup or invitation should have a test-safe destination. The expected outcome should be precise enough to distinguish a duplicate action from a successful single action. This is especially useful when a form can be submitted twice.
Add a Cypress spec for {{journey}} using {{existing_spec}} as the style.
Read the config and setup helpers. Define the test-owned records and the
visible completion condition. Cover {{success_case}} and {{failure_case}}.
Keep the test independent of other specs and external live accounts.
Run the relevant spec and report the exact observed result.
Control a request to test recovery
A loading or failure state can be difficult to catch with a live service. Provide the response contract and ask the agent to control that boundary. Review what the fixture omits: a successful fake response that lacks required fields can make the test exercise a different path from production. The recovery action should lead to a fresh observable result.
Use Cypress network interception to test {{request}} in {{spec_path}}.
Model delayed success, {{error_response}} and a successful retry.
Match requests precisely so unrelated traffic is not intercepted.
Check what the user sees during each transition. Explain which production
behavior remains outside this stubbed test and needs integration coverage.
Investigate failures without hiding the cause
Start with the first failed assertion, not the last screenshot. Ask whether the selected element was stale, the request never completed or shared data changed underneath the test. A useful diagnosis names the missing evidence and proposes a small experiment. Increasing retries can help collect evidence, but it is not proof that the underlying defect disappeared.
Diagnose {{failure_output}} for {{spec_path}} using {{run_artifacts}}.
Compare a failed and passing run if available. Identify the earliest
observable divergence. Replace fixed delays only after naming the event
or condition that should be awaited. Check setup and cleanup for shared
state. Re-run in the failing environment when available; state any gap.
Preserve the useful boundary
Review whether each assertion tests application behavior or merely the fixture you supplied. Keep a small number of real integration checks for important service boundaries that the stubs bypass. If an environment restriction blocks execution, record the proposed command and missing dependency without presenting the spec as passing.
Keep the approved Cypress prompt in Kipt with blanks for spec, journey and run artifacts. Use the API testing prompts when the bug lies in the service contract rather than the browser interaction.