---
name: e2e-coverage-analyzer
description: 分析当前分支 git 改动，检查 e2e 测试用例覆盖情况，并可补充缺失的测试用例
allowed-tools:
  - Bash(git diff:*)
  - Bash(git --no-pager diff:*)
  - Bash(git merge-base:*)
  - Bash(git branch --show-current:*)
  - Bash(ls:*)
  - Bash(find:*)
  - Read
  - Glob
  - Grep
  - Write
  - Bash(mkdir:*)
---

# E2E 覆盖率分析器

分析当前分支相对于 main 的改动，评估 `tests/e2e/` 中现有测试用例是否足以覆盖改动涉及的功能点。

## 上下文

- 当前分支: !`git branch --show-current`
- 分叉点 commit: !`git merge-base main HEAD`
- 改动文件列表: !`git --no-pager diff --name-only main...HEAD`
- 改动内容摘要（统计）: !`git --no-pager diff --stat main...HEAD`
- 改动详细内容: !`git --no-pager diff main...HEAD`

## 现有 e2e 测试用例清单

!`find tests/e2e -maxdepth 1 -type d ! -path tests/e2e | sort`

## 你的任务

按以下四个阶段执行，每个阶段输出清晰的中文报告。

---

### 阶段一：改动分析

1. **过滤核心逻辑文件**：从改动文件列表中排除以下非逻辑文件类型：
   - 配置文件：`*.config.*`, `*.env*`, `tsconfig*.json`, `.eslintrc*`, `.prettierrc*`
   - 类型定义文件：`*.d.ts`, `types/*.ts`, `interfaces/*.ts`
   - 文档和说明文件：`*.md`, `CHANGELOG*`, `LICENSE*`
   - 锁定文件：`package-lock.json`, `pnpm-lock.yaml`, `yarn.lock`
   - CI/CD 配置：`.github/**`, `.gitlab-ci*`, `Dockerfile*`, `docker-compose*`
   - 测试文件本身：`**/*.test.ts`, `**/*.spec.ts`, `tests/**`, `__tests__/**`

   **保留**以下类型的文件作为核心逻辑文件：
   - `src/web/**` 下的组件、页面、hooks、store、工具函数
   - `src/server/**` 下的服务、路由、控制器、中间件、处理器
   - `src/` 下各模块的源码逻辑文件

2. **识别功能点**：对每个核心逻辑文件，结合 git diff 的实际改动内容，分析其涉及的功能维度：
   - **页面/路由**：涉及哪个页面或路由（如 `/dashboard`）
   - **UI 组件**：涉及哪些 UI 组件（如 MCP 工具表格、对话框、表单等）
   - **交互行为**：涉及的点击、输入、切换、拖拽等用户操作
   - **数据流**：涉及的数据请求、状态变更、事件处理
   - **视觉呈现**：涉及的新增/修改的 UI 元素、样式变化

3. **输出改动分析报告**，格式如下：

   ```
   === 改动分析报告 ===

   核心逻辑文件（共 N 个）：
   1. src/web/pages/Dashboard.tsx
      - 涉及页面：Dashboard 页面
      - 涉及功能点：新增状态卡片 X、修改表格列 Y

   排除的非逻辑文件（共 M 个）：
   - package.json（依赖变更）
   ...
   ```

---

### 阶段二：覆盖匹配

1. **读取所有现有 e2e 测试用例**：遍历 `tests/e2e/` 下每个子目录中的 `test.md` 文件，提取每个用例覆盖的功能点关键词。

2. **建立映射关系**：将阶段一识别的功能点与现有测试用例进行匹配。匹配规则：
   - **精确匹配**：测试用例名称或步骤明确提及了改动的功能点
   - **关联匹配**：测试用例覆盖了改动所在的页面/组件区域，虽然未直接测试该具体改动，但执行路径会经过相关代码
   - **无匹配**：改动涉及的功能点没有任何测试用例覆盖

3. **输出覆盖匹配报告**，格式如下：

   ```
   === 覆盖匹配报告 ===

   已覆盖的功能点：
   | 功能点 | 匹配测试用例 | 匹配类型 |
   |--------|-------------|---------|
   | Dashboard 页面加载 | 测试Dashboard页面加载 | 精确匹配 |

   缺少覆盖的功能点：
   | 功能点 | 涉及文件 | 风险等级 |
   |--------|---------|---------|
   | 新增的 XXX 功能 | src/web/components/XXX.tsx | 高 |

   覆盖率总结：
   - 总功能点数：N
   - 已覆盖：M（X%）
   - 未覆盖：K（Y%）
   ```

   **风险等级判定标准**：
   - **高**：涉及新的用户可见功能或交互流程变更
   - **中**：涉及已有功能的逻辑修改或边界条件变化
   - **低**：涉及内部实现优化、重构、错误处理改进

---

### 阶段三：结论与建议

根据覆盖匹配结果输出结论：

**如果全部覆盖（覆盖率 100%）**：

```
=== 结论 ✅ ===

当前分支的所有改动均有对应的 e2e 测试用例覆盖：

[列出所有匹配关系]

建议：可以直接提交 PR，或在提交前运行 /e2e 执行全量测试验证。
```

**如果存在未覆盖项**：

```
=== 结论 ⚠️ ===

当前分支存在 N 个缺少 e2e 覆盖的功能点：

[高优先级]
1. [功能点描述] — 涉及文件：xxx

[中优先级]
2. ...

是否需要为这些缺失的功能点创建新的 e2e 测试用例？
回复"是"将继续创建，回复"否"则仅保留上述报告。
```

**特殊情况处理**：
- 如果当前分支与 main 无差异（无改动），直接提示用户并退出
- 如果改动仅涉及非逻辑文件（纯配置、文档等），提示用户无需 e2e 覆盖并退出

---

### 阶段四：创建测试用例（仅在用户确认后执行）

当用户确认需要补充测试用例时：

1. **确定要创建的测试用例列表**：按风险等级从高到低排列。

2. **为每个缺失的功能点创建 e2e 测试用例**，遵循以下规范：

   a. **目录命名**：使用中文 `测试<功能描述>` 格式，例如：
      - `tests/e2e/测试新功能名称/`

   b. **test.md 格式**：
      ```markdown
      ## 前置条件（可选）
      如有特殊前置条件在此说明

      ## 测试步骤
      1. 打开页面 http://localhost:9999/dashboard
      2. 等待页面加载完成
      3. [具体的操作步骤]
      4. 截图（关键状态描述）
      5. [验证断言]
      ```

   c. **编写原则**：
      - 每个步骤是单一、可执行的原子操作
      - 使用元素的可辨识特征定位（title、placeholder、文本内容、图标描述）
      - 关键状态变化后必须截图
      - 必须包含明确的验证断言
      - 如需清理测试数据，在最后一步说明

   d. **参考现有用例的风格**：参考已有的测试用例写法保持一致

3. **输出创建结果报告**：

   ```
   === 测试用例创建报告 ===

   已创建以下 e2e 测试用例：

   1. tests/e2e/测试XXX/test.md
      - 覆盖功能点：...
      - 步骤数：N

   创建完成后可使用以下命令执行：
   /e2e tests/e2e/测试XXX
   ```

## 注意事项

- 本技能只进行分析和测试用例创建，不执行测试。执行测试请使用 `/e2e` 命令。
- 所有输出使用中文。
- 分析时重点关注用户可感知的功能变化，不过度追求理论上的完美覆盖。