---
name: e2e-generate
description: Generate Playwright tests and page object updates from a module spec markdown file
---

# /e2e-generate - Generate Tests from Spec

Convert a module spec into executable Playwright tests that follow Humand conventions.

## Workspace

This skill supports two layouts:

- **Single-app** (`<root>/e2e/playwright.config.ts`): resolve `<workspace>/` to `e2e/`.
- **Multi-app** (`<root>/<app>/playwright.config.ts` per app, e.g. `web/`, `backoffice/`): resolve `<workspace>/` to that app's folder.

Detect by probing for `playwright.config.ts`. The `specPath` argument typically pins which workspace is in play (`web/specs/...` → `web` workspace). If ambiguous, ASK before proceeding.

## Scope

- Works inside the resolved E2E workspace.
- Consumes `<workspace>/specs/*.spec.md`.
- May update `<workspace>/tests/{module}/`, `<workspace>/pages/`, and `<workspace>/fixtures/base.fixture.ts`.

## Knowledge References

### Required

1. `knowledge/patterns/page-objects.md`
2. `knowledge/writing-tests/locators.md`
3. `knowledge/writing-tests/assertions.md`
4. `knowledge/writing-tests/fixtures.md`
5. `knowledge/writing-tests/test-organization.md`
6. `knowledge/humand/conventions.md`
7. `knowledge/humand/configuration.md`

### Conditional

1. `knowledge/patterns/react-patterns.md`
2. `knowledge/patterns/data-management.md`
3. `knowledge/patterns/api-interception.md`
4. `knowledge/patterns/authentication.md`
5. `knowledge/writing-tests/forms.md`

Resolve which conditional docs apply before editing code, and list them in your working response.

Also follow:

- `rules/playwright-generator.mdc`

## Inputs

- `specPath` (required)
- `targetFolder` (optional, defaults to `<workspace>/tests/{module}/`)

If `specPath` is missing, ask once and continue.

## Workflow

### 0) Resolve app context

Read `.e2e/context.local.json`. If missing, suggest running `/e2e-setup` first. If the dev opts to proceed without it, run in **degraded mode** — generate from spec only, without cross-referencing app source code or translations.

When the target workspace matches an `apps[<name>]` key (e.g. workspace `web` ↔ `apps.web`), use that app's `repoPath` to read translation files for accurate ES locator text and to inspect components for naming alignment.

### 1) Resolve the workspace and inspect the local contract

Resolve `<workspace>/` from `specPath`. Then read:

- the local `package.json` (workspace root in single-app, repo root in multi-app)
- `<workspace>/playwright.config.ts`
- `<workspace>/tests/auth.setup.ts`
- `<workspace>/fixtures/base.fixture.ts`
- existing module tests/pages when present

Then confirm:

- the local Playwright/auth/locale contract
- the correct fixture import path
- whether existing module artifacts should be reused or replaced
- whether the spec is precise enough to generate code safely

### 2) Generate page objects and tests

- Reuse existing page objects when they still define the right module boundaries.
- Keep interactions inside page objects.
- Prefer accessible locators, but verify non-standard regions before assuming roles or labels.
- Scope drawers and slide-ins under `[role="presentation"]` when needed.
- Use isolated test data with unique names for every mutating test.
- Never assert rows by shared or generic text.
- Prefer durable outcome assertions when snackbar behavior is unreliable.
- If a region is still not reliably targetable after inspection, prefer a narrow `test.fixme()` over a guessed selector.

### 3) Update fixtures only where needed

- Register new page objects in `<workspace>/fixtures/base.fixture.ts`.
- Keep fixture creation thin and typed.
- During benchmark resets, touch only the module-specific slice.

### 4) Validate

- Validate generated flows against the live app when feasible.
- Run the narrowest useful Playwright scope through the local `package.json` contract before finishing (e.g. `npx playwright test --config=<workspace>/playwright.config.ts <test-path>`).

## Out of scope

- exploratory planning
- failure diagnosis loops after reproduction