技能介绍

要解决的问题

接手一个前端项目时，端到端测试往往是最先被跳过的一环。Playwright 本身能力不弱，但要真正用起来，需要做一堆琐碎决策：装哪个版本的 @playwright/test、playwright.config.ts 里的 baseURL 填什么、开发服务器由谁来拉起、测试文件放哪个目录、CI 里该加什么 job、package.json 要补哪几条 script。每个框架的默认端口和启动命令都不一样，凭记忆手写配置很容易翻车——比如给 Angular 项目配了 npm run dev，CI 就会一直卡在启动超时。这个技能把这些决策和执行打包成一个固定流程，让环境搭建从「翻文档 + 反复试错」变成一次跑完。

核心能力与工作流程

执行分成几个明确的阶段：

项目探测：先用 Explore 子代理扫描仓库，确认 package.json 里的框架（React、Next.js、Vue、Angular、Svelte）、是否存在 tsconfig.json（决定 TypeScript 还是 JavaScript）、是否已装过 Playwright、是否已有 tests/、e2e/、__tests__/ 目录，以及是否已有 .github/workflows/ 或 .gitlab-ci.yml。
安装依赖：未安装时自动安装，也允许用户选择手动处理。
生成配置：根据探测到的框架定制 playwright.config.ts，React(Vite) 对应 http://localhost:5173 与 npm run dev，Vue/Nuxt 对应 3000 端口，Angular 对应 4200 端口与 npm run start；若没探测到框架，则省略 webServer 块，baseURL 由用户输入或留占位符。
落地文件：创建目录结构与示例测试，并按现有 CI 类型决定是新增 playwright.yml，还是往 .gitlab-ci.yml 里加一个 Playwright stage。
收尾验证：更新 .gitignore、补充 package.json 的 scripts，最后真正执行一次示例测试，失败就现场诊断修复，通过才算完成。

结束时会列出生成了哪些文件、关键配置项是什么，以及如何运行（npx playwright test 或 npm run test:e2e）。

适用边界

需要注意几点：技能只负责搭建骨架，示例测试本身只验证连通性，不代表业务覆盖度。它依赖项目已有的 Node 环境与包管理器，且 webServer 配置假设项目有标准的 dev/start 脚本。遇到自定义端口、代理转发或 monorepo 子包时，生成的配置需要人工再调。另外，若项目里已存在测试目录和 CI 流水线，技能是追加而不是覆盖，动手前最好先确认它会写哪些文件。