# E2e Gen

> Two-stage E2E skill: a gate check that decides whether the change has browser-verifiable UI behavior (writes e2e:gate-passed or e2e:skipped trace events, generates nothing), and a generation stage entered only after the user confirms generation. Generates e2e-cases.yaml from prd.md, plan.md, and contract.md, plus e2e-config.yaml on first run.

- Skill: `mrlyk/e2e-gen` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add mrlyk/e2e-gen`
- Raw SKILL.md: https://api.skillmd.com/api/skills/mrlyk/e2e-gen/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: mrlyk (https://skillmd.com/u/mrlyk)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/mrlyk/e2e-gen

---


# E2E Case Generation

Two stages:

1. **Gate check** — decide whether browser E2E cases apply to this change. Writes trace events only; generates no files. Whether to generate is the user's later choice, never this stage's.
2. **Generation** — entered only after the user has confirmed generation.

This file contains ONLY the decision gates. The full generation procedure (config generation, case format, mock rules, validation) lives in `./references/generation.md` and is read ONLY when the generation stage starts. Do not read it during gate check; do not skip it during generation.

**Announce at start:** gate check — "I'm using the e2e-gen skill to run the E2E gate check." Generation — "I'm using the e2e-gen skill to generate E2E test cases."

## Gate 1 — Does the Project Have a UI?

1. Check project structure: frontend framework configs (next.config, vite.config, angular.json, .vue files, etc.)
2. Check prd.md content: does it mention pages, interfaces, interactions, or user-visible behavior?
3. Check package.json scripts: `dev`, `start`, `serve`, or similar scripts that launch a UI?

**If no UI:** skip via the [Skip Protocol](#skip-protocol) with reason "project has no UI".
**If UI exists:** proceed to Gate 2. A project having a UI is NOT sufficient to generate — Gate 2 decides.

## Gate 2 — Does THIS Change Have Browser-Verifiable UI Behavior?

A fullstack project always passes Gate 1, but a backend-only task in it must still skip. Judge the CHANGE, not the project.

Read `contract.md`'s Done Definition and label each acceptance criterion, in order, as `browser-required: yes/no` using these rules:

<BROWSER-REQUIRED-RULES>
1. A criterion is browser-required ONLY IF verifying it needs browser rendering or interaction: DOM state, visual feedback, user input flows, client-side routing, or console errors.
2. If the criterion can be fully verified with HTTP assertions alone (status code, headers, response body) — i.e. curl could verify it — it is NOT browser-required. That behavior belongs to API/integration tests.
3. Only the project's OWN UI assets (components/pages written in this repo) count as UI. Framework-served pages (Swagger UI, ReDoc, default error pages) are NOT project UI; criteria about them are NOT browser-required.
4. Label criteria one by one; on the FIRST `yes`, stop labeling — the gate passes, follow the Gate-Passed Protocol.
5. If ALL criteria are `no`, skip via the Skip Protocol.
</BROWSER-REQUIRED-RULES>

**If the gate passes:** follow the [Gate-Passed Protocol](#gate-passed-protocol). Generation does NOT start here.

## Gate-Passed Protocol

When Gate 2 finds a browser-required criterion:

1. Log an `e2e:gate-passed` event to the task's trace:

   ```bash
   superharness task e2e {task} passed --detail "<first browser-required criterion, one sentence>"
   ```

   The event tells the user-prompt-submit hook that the gate check ran, so it stops re-prompting while the user's decision is pending.

2. Tell the user in one sentence that the change has browser-verifiable UI behavior and generation awaits their confirmation.

3. Do NOT generate `e2e-config.yaml` or `e2e-cases.yaml`. Do NOT read `./references/generation.md`. Do NOT ask the user any questions. Return.

## Generation Stage

Entered only after the user confirms generation. READ `./references/generation.md` IN FULL and follow it. For mixed tasks (some criteria `yes`, some `no`), generate cases only for the `yes` criteria; the `no` criteria are recorded as exemptions during the contract cross-check step there.

## Skip Protocol

When either gate decides to skip:

1. Log an `e2e:skipped` event to the task's trace:

   ```bash
   superharness task e2e {task} skipped --detail "<one sentence reason>"
   ```

   The event exists for the user-prompt-submit hook: its gate check treats it as proof that e2e-gen ran and decided to skip, so it stops re-prompting the invocation every turn.

2. Tell the user the same one-sentence reason — e.g. "变更只涉及后端文档路由的开关与 404 行为，全部验收点可由 HTTP 断言覆盖". No confirmation needed — the plan review step covers it.

3. Do NOT generate `e2e-config.yaml` or `e2e-cases.yaml`. Do NOT ask the user any questions. Return.

## Red Flags

- **Don't** generate browser E2E for behavior fully verifiable via HTTP assertions — that belongs to integration tests
- **Don't** treat framework-served pages (Swagger UI, ReDoc, error pages) as project UI
- **Don't** skip on gut feeling — walk the labeling rules over the Done Definition before deciding
- **Don't** generate any E2E file during gate check — even when the gate passes, generation waits for the user's confirmation
- **Don't** read `./references/generation.md` before the user confirms generation; **don't** proceed to generation without reading it in full
- **Don't** ask the user ANY questions at gate stage