E2E自动化工程师 端到端流程测试

SKILL.md

---
name: E2E自动化工程师-端到端流程测试
description: E2E automation engineer skill for Playwright-driven flow validation, browser interaction coverage, and end-to-end regression checks.
---

# Role

This skill validates real user flows through browser automation and route-backed execution. It focuses on full-path behavior, cross-page interactions, and integration correctness that cannot be proven by unit tests alone.

# When To Use

- Use for Playwright, browser flow testing, multi-step UI paths, and end-to-end regression checks.
- Use for keywords such as E2E, Playwright, browser flow, end-to-end, UI interaction, and acceptance path.
- Use when the changed behavior crosses multiple controllers, pages, or services.

# Source Material

- `AI-ENTRY.md`
- `CLAUDE.md`
- `dev/ai/skills/testing/SKILL.md`
- `dev/ai/skills/sse-streaming/SKILL.md`
- `dev/ai/skills/weline-routing/SKILL.md`

# Responsibilities

- Validate the real user journey, not just one rendered fragment.
- Use the repository-supported Playwright execution path.
- Keep E2E scope focused on behavior that needs browser-level proof.
- Return actionable evidence when a user flow breaks.

# Workflow

1. Identify the exact business flow that needs end-to-end proof.
2. Choose the narrowest spec, case id, or grep target that covers the changed behavior.
3. Prepare any required isolated runtime or route state before running the browser check.
4. Run the supported framework E2E command rather than an ad hoc runner path.
5. Inspect failures at the user-flow step where behavior diverges.
6. Re-run the smallest confirming scope after fixes.
7. Report the executed scenario, result, and remaining gaps.

# Weline Rules

- Use `php bin/w e2e:run` for repository-supported browser testing.
- Provide E2E or HTTP validation evidence where relevant.
- Do not use default WLS port `9501` for AI testing if the flow depends on a dedicated instance.
- Always stop dedicated WLS instances after runtime-sensitive E2E validation.

# Inputs Required

- The user flow, module, and target pages.
- Any login, seed data, or runtime prerequisites.
- The preferred spec file, module filter, case id, or grep scope.
- Expected success criteria for the browser journey.

# Expected Output

- A focused E2E execution result tied to the changed flow.
- Clear pass or failure evidence for the real browser path.
- Notes about any prerequisite setup or residual risk.

# Validation

- Run `php bin/w e2e:run` with the smallest scope that still proves the behavior.
- Confirm the validated path covers the actual changed user flow.
- Confirm the runtime or route prerequisites match the production-style path.
- Confirm any dedicated runtime instance is cleaned up after use.

# Constraints

- Do not replace real browser validation with only unit evidence when the risk is end-to-end.
- Do not run unsupported Playwright invocation patterns from the wrong directory context.
- Do not bloat one E2E check into a full unrelated suite unless necessary.
- Do not hide flaky prerequisites; report them explicitly.