القائمة
E2E测试设计完整性检查与完善。对测试实现分析报告进行深度检查，包括变更点覆盖分析、外部依赖异常场景、测试数据设计完善。当用户说"/e2e-varify"、"完善测试设计"、"验证测试用例"、"测试用例审查"，或需要将测试设计草稿打造成完善的可指导测试代码落地的文档时使用此技能。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
按 Git/非 Git、是否指定 BRANCH_NAME 与 FEATURE_DIR 分支决策，解析输入并创建或复用特性分支与功能目录，输出 BRANCH_NAME、SPEC_FILE、FEATURE_DIR。用于 /specify 或单独创建/复用特性分支。
基于已定义的功能识别并调整逻辑实体，输出实体责任边界、协作关系与关键数据结构，并生成数据模型文档。仅被显式调用，不自动触发。
SDD流程代码变更采集Skill。在SDD流程执行完毕后，采集目标目录的代码变更信息，提取feature_infos和code_blocks，生成评测所需的JSON文件并保存到当前SDD分支的evalset目录下。当用户提到"采集SDD变更"、"生成评测数据"、"收集代码变更信息"、"build_configi_eval"、"evalset"时触发本技能。
深度逻辑架构要素反构编排Skill. 当 reverse 的 --target 为 deep_logic_architecture 时触发.
实体清单与实体关系反构的编排Skill. 当 reverse 的 --target 为 entities 或 all 的实体阶段时触发.
功能清单与功能详情文档反构的编排Skill. 当 reverse 的 --target 为 functions 或 all 的功能阶段时触发.
| name | e2e-varify |
| description | E2E测试设计完整性检查与完善。对测试实现分析报告进行深度检查，包括变更点覆盖分析、外部依赖异常场景、测试数据设计完善。当用户说"/e2e-varify"、"完善测试设计"、"验证测试用例"、"测试用例审查"，或需要将测试设计草稿打造成完善的可指导测试代码落地的文档时使用此技能。 |
$ARGUMENTS
在继续之前, 你必须考虑用户输入(如果不为空).
执行 E2E 测试设计的完整性检查和完善工作流，作为 e2e-design 的下游动作。
调用场景：
e2e-design 生成 e2e-impl-design.md 后自动执行输入要求：
spec.md：功能规范文档design.md：设计文档e2e-test.md：黑盒测试用例文档e2e-impl-design.md：测试实现分析报告（e2e-design 输出）输出：
e2e-impl-design.md：完善的测试实现分析报告scripts/powershell/check-prerequisites.ps1 --json --require-e2e-impl-designscripts/bash/check-prerequisites.sh --json --require-e2e-impl-designFEATURE_DIR（特性目录绝对路径）SPEC_FILE（规范文件路径）DESIGN_FILE（设计文件路径）E2E_TEST_FILE（黑盒测试用例文件路径）E2E_IMPL_DESIGN_FILE（测试实现分析报告路径）AVAILABLE_DOCS（可用文档列表）重要：所有路径必须是绝对路径。
验证以下必需文件是否存在：
检查规范文件：
{FEATURE_DIR}/spec.md 是否存在检查设计文件：
{FEATURE_DIR}/design.md 是否存在检查测试用例文件：
{FEATURE_DIR}/e2e-test.md 是否存在检查测试实现分析报告：
{FEATURE_DIR}/e2e-impl-design.md 是否存在报告验证结果：
加载用于测试设计完善的上下文文档：
必需文档：
可选文档（按优先级加载）：
baseline 文档：
baseline/code-structure.md：现有代码结构baseline/existing-apis.md：现有接口定义baseline/call-graph.md：调用链路（用于确定外部依赖）baseline/detailed-design.md：现有架构设计存量测试代码：
tests/、test/）加载策略：
识别需求变更点：
生成变更点清单： 从本次需求变更内容的角度，梳理变更点清单，格式如下：
## 变更点清单
| 变更点编号 | 变更描述 | 影响模块 | 影响接口 |
| ---------- | -------- | -------- | -------- |
| CP-001 | ... | ... | ... |
| CP-002 | ... | ... | ... |
生成用例覆盖表： 查看是否所有变更点在 e2e-test.md 和 e2e-impl-design.md 中都有覆盖，输出对应表：
## 变更点用例覆盖表
| 变更点 | 用例编号 | 覆盖状态 | 备注 |
| ------ | -------- | -------- | ---- |
| CP-001 | TC-001 | ✅ | |
| CP-002 | TC-002 | ✅ | |
| CP-003 | - | ❌ | 需补充 |
应用以下规则设计用例，将设计的用例及时回写到 e2e-impl-design.md 文档中：
查找存量测试代码：
tests/、test/、*_test.go、*_test.py 等）识别核心测试场景：
补充测试用例：
将识别出的核心模块测试用例添加到 e2e-impl-design.md 的用例实现映射表中。
提取外部交互点： 分析 e2e-impl-design.md 中的"外部依赖详细分析"章节，找出每个用例与外部系统进行交互的地方。
设计异常场景用例： 针对每个外部依赖，考虑以下异常情况：
a) HTTP 接口交互：
b) 数据库 IO 操作：
c) 消息队列交互：
d) 文件系统操作：
补充异常用例：
将设计出的异常场景用例添加到 e2e-impl-design.md 中，并更新变更点覆盖表。
分析测试数据需求： 逐个遍历测试用例条目的测试数据，列出需要的数据清单。
构造测试数据：
参考存量测试数据： 遇到不确定的地方，先查找存量代码库中测试代码是否有类似的用例，然后根据这些用例构造方式进行数据构造。
标注风险点： 最终每个数据需要给一个检查建议，对于可能构造错误的数据标注出：【必须关注】
补充到文档： 构造数据的设计内容，补充到 e2e-impl-design.md 文档中，格式如下：
### TC-XXX: [用例名称]
**测试数据**：
- 输入数据：
```json
{具体数据}
{具体数据}
{具体数据}
将完善的内容更新到 e2e-impl-design.md 文档中：
添加新章节：
更新现有章节：
更新覆盖表： 确认是否所有变更点都有对应的测试用例覆盖
检查覆盖完整性：
生成完善报告： 输出以下统计信息：
输出风险清单： 列出所有标注为 【必须关注】 的测试数据项，提示实施时重点关注。
输出完成报告，包括：
更新文档：
完善统计：
风险提示：
下一步建议：
/tasks 生成任务列表/e2e-varify前置文件缺失：
变更点覆盖不全：
测试数据构造失败：
变更点覆盖：
异常场景设计：
测试数据具体化：
复用存量设计：
测试设计完善后，可继续执行：