write-e2e-tests

Writes Cypress end-to-end tests for user flows following repository conventions.

Updated Apr 9, 2026
One-click install
npx skills add https://github.com/muselesscreator/ui-skills --skill write-e2e-tests-muselesscreator
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: write-e2e-tests
Source: https://github.com/muselesscreator/ui-skills/tree/main/write-e2e-tests
Command: npx skills add https://github.com/muselesscreator/ui-skills --skill write-e2e-tests-muselesscreator

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Writing E2E tests that match a project's established conventions is slow and error-prone: you must learn the intercept patterns, page object structure, and wait strategies before writing a single assertion. This Skill loads those conventions automatically and produces tests that fit the existing suite. ## Core Features & Use Cases - Convention Loading: Reads repo-specific E2E patterns (intercepts, page objects, wait strategy) via a test-context step before writing any test. - Pattern-Consistent Test Generation: Searches existing Cypress specs, reuses page objects, and enforces rules like network-based waits instead of arbitrary timeouts. - Verification Loop: Runs the new spec headlessly, diagnoses failures from screenshots and DOM comparison, and writes a structured coverage report. - Use Case: After shipping a new checkout flow, ask for E2E coverage and receive a passing Cypress spec with intercepts, page objects, and happy-path plus error-state cases. ## Quick Start Ask the assistant to write E2E tests for a specific user flow, describing the start state, actions, and expected end state.

Frequently Asked Questions about write-e2e-tests

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

FAQPage Schema
How do I write Cypress E2E tests for a user flow?

Describe the flow's start state, user actions, and expected end state. The Skill loads your repo's E2E conventions, finds similar existing specs, plans intercepts and page objects, then writes and runs the test to confirm it passes.

How to avoid flaky Cypress tests with cy.wait timeouts?

Wait for specific network events using intercepts and aliases instead of arbitrary timeouts like cy.wait(5000). This Skill enforces intercept-before-action patterns and the project's established wait strategy so tests stay deterministic.

Does this work with existing page objects in my repo?

Yes. It searches existing E2E specs, reuses current page objects where possible, and creates new ones following the same structure. Raw cy.get() selectors in test files are avoided in favor of page object abstractions.

What happens when a newly written E2E test fails?

The Skill runs the new spec headlessly, and on failure diagnoses the root cause by checking screenshots and comparing selectors against the actual DOM before reporting. It does not report a failing test as complete.

When should I not use automated E2E test generation?

Avoid it when the repo has no established E2E conventions to follow, since generated tests would lack consistent patterns. It also fits poorly for unit-level logic, which is better covered by faster unit or integration tests.