How do I install the Opal Frontend Cypress E2e skill?

Run npx skillmds add majiayu000/opal-frontend-cypress-e2e in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Opal Frontend Cypress E2e safe to use?

This skill has not completed SkillMD's automated safety review yet. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Opal Frontend Cypress E2e?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Opal Frontend Cypress E2e free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Opal Frontend Cypress E2e?

majiayu000 (@majiayu000) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Opal Frontend Cypress E2e by majiayu000

Name: Opal Frontend Cypress E2e
Rating: 4.2 (5 reviews)
Author: majiayu000

Opal Frontend Cypress E2e

Cypress end-to-end testing guidance for opal-frontend, including Cucumber feature layout, tags, step definitions, Actions or Flows, selectors, and accessibility specs. Use when adding or updating E2E scenarios.

majiayu000 1dec6ad 2 files · 3.0 KB Updated Sep 9, 2026 567 repo stars

File contents

Opal Frontend Cypress E2E Testing

Overview

Use these rules when writing or updating Cypress E2E tests and Cucumber feature files in opal-frontend.

Required References

For any E2E scenario creation or update, read references/E2E_New_Feature_Codex_Optimized_Instructions.md and follow it as the governing ruleset.
Keep references/E2E_Refactor_Codex_Optimized_Instructions.md as legacy reference material; consult it only when explicitly requested or when refactoring older features that need its legacy guidance.

Feature Layout and Tags

Preferred home is cypress/e2e/functional/opal.
Feature files live under capability folders (for example, features/manualAccountCreation/**, features/fineAccountEnquiry/**).
Tag scenarios with @functional, @smoke, and Jira IDs so suites can target subsets.
Keep legacy suites in cypress/e2e/Old_functional_E2E_Tests; new scenarios should follow the opal layout.

Accessibility Coverage

Accessibility specs live alongside features and should navigate to each page, inject axe-core, run scans, and assert no violations.
When a new page or view is added to a feature, add or update its accessibility spec.

Step Definitions

Step definitions in cypress/support/step_definitions/** must be thin shims.
Each Given, When, Then should delegate to a single Action or Flow method.
Shared DB or setup logic belongs in databaseSteps or support/utils, not in steps.

Actions, Flows, and Selectors

Actions in cypress/e2e/functional/opal/actions/** wrap interactions, API stubs, and navigation using selectors from cypress/shared/selectors/**.
Flows in cypress/e2e/functional/opal/flows/** compose actions into business journeys and are the verbs exposed to steps and component specs.
Selectors are centralized. Add hooks in Angular templates and document them in cypress/shared/selectors/**. Avoid positional CSS.

Running a Feature

Run a single feature file with: yarn cypress run --browser chrome --spec 'cypress/e2e/functional/opal/features/manualAccountCreation/populateAndSubmit/PopulateAndSubmit.feature'

Handling Real Product Bugs

When a feature fails because of a real product bug, do not patch application behavior just to green the test.
Skip or xfail the test if unavoidable and report the underlying issue in the task update.

---name: opal-frontend-cypress-e2edescription: Cypress end-to-end testing guidance for opal-frontend, including Cucumber feature layout, tags, step definitions, Actions or Flows, selectors, and accessibility specs. Use when adding or updating E2E scenarios.--- # Opal Frontend Cypress E2E Testing ## Overview Use these rules when writing or updating Cypress E2E tests and Cucumber feature files in opal-frontend. ## Required References - For any E2E scenario creation or update, read `references/E2E_New_Feature_Codex_Optimized_Instructions.md` and follow it as the governing ruleset. - Keep `references/E2E_Refactor_Codex_Optimized_Instructions.md` as legacy reference material; consult it only when explicitly requested or when refactoring older features that need its legacy guidance. ## Feature Layout and Tags - Preferred home is `cypress/e2e/functional/opal`. - Feature files live under capability folders (for example, `features/manualAccountCreation/**`, `features/fineAccountEnquiry/**`). - Tag scenarios with `@functional`, `@smoke`, and Jira IDs so suites can target subsets. - Keep legacy suites in `cypress/e2e/Old_functional_E2E_Tests`; new scenarios should follow the `opal` layout. ## Accessibility Coverage - Accessibility specs live alongside features and should navigate to each page, inject `axe-core`, run scans, and assert no violations. - When a new page or view is added to a feature, add or update its accessibility spec. ## Step Definitions - Step definitions in `cypress/support/step_definitions/**` must be thin shims. - Each Given, When, Then should delegate to a single Action or Flow method. - Shared DB or setup logic belongs in `databaseSteps` or `support/utils`, not in steps. ## Actions, Flows, and Selectors - Actions in `cypress/e2e/functional/opal/actions/**` wrap interactions, API stubs, and navigation using selectors from `cypress/shared/selectors/**`. - Flows in `cypress/e2e/functional/opal/flows/**` compose actions into business journeys and are the verbs exposed to steps and component specs. - Selectors are centralized. Add hooks in Angular templates and document them in `cypress/shared/selectors/**`. Avoid positional CSS. ## Running a Feature - Run a single feature file with: `yarn cypress run --browser chrome --spec 'cypress/e2e/functional/opal/features/manualAccountCreation/populateAndSubmit/PopulateAndSubmit.feature'` ## Handling Real Product Bugs - When a feature fails because of a real product bug, do not patch application behavior just to green the test. - Skip or xfail the test if unavoidable and report the underlying issue in the task update.

Frequently asked questions