e2e-gen

name	e2e-gen
description	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.
allowed-tools	Bash(superharness:*), Bash(npm:*), Bash(pnpm:*), Bash(yarn:*), Read, Write

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 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:

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.

If the gate passes: follow the 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:

   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:

   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