ui-test-cypress

Cypress 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 Cypress UI automation testing workflow.
When the project already uses the relevant tools, or you want a tool-specific plan that can be directly implemented.

Markdown is used by default. Unless the request explicitly asks for another format, do not extend the output format further.

Open prompts/ui-test-cypress.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 references/domain-decision-example.md 's desensitized input, item-by-item expectations, and recomputation basis.
prompts/ui-test-cypress.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.

Confirm the Cypress, Node, and browser versions and the component/E2E boundary from the project lockfile/config; generate configuration, custom commands, specs, and CI commands according to that version, and do not upgrade by default or mix in old configurations.
Preserve real pages/components and business logic; cy.intercept only replaces confirmed external boundaries; verifying only stub responses is not enough to prove real postconditions. Clarify fixture data and session isolation/logout.
Distinguish between retryable queries/assertions and actions that execute once, as well as whole-test retries; wait on aliased requests/observable states rather than sleep, and retries must not mask the first failure or duplicate side effects.
Use a minimal application positive/negative comparison to verify order status/amount/subject after payment; a normal title but a business error must cause the assertion to fail and CI to be non-zero. Record screenshots/videos/original failures, teardown, and real execution evidence; the existence of a file does not equal a pass.

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

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 at explicit runtime.