完善skills；测试用例生成页面功能初步实现

.github/skills/METHOD_ID_REGISTRY.md

@@ -0,0 +1,45 @@
+# METHOD_ID_REGISTRY
+
+## Purpose
+Provide a single source of truth for test method identifiers used across skills.
+
+## Format
+- Recommended output format: `Mxx|方法名`
+- Routing key: `Mxx`
+- Display name: 方法名
+
+## B.1 Black-box Methods (M01-M12)
+| Method ID | 方法名 | 推荐占位符 | Route Skill |
+| --- | --- | --- | --- |
+| M01 | 功能分解 | {{return_value}}, {{state_change}} | generate-test-cases-blackbox |
+| M02 | 等价类划分 | {{return_value}}, {{error_message}} | generate-test-cases-blackbox |
+| M03 | 边界值分析 | {{return_value}}, {{precision_tolerance}} | generate-test-cases-blackbox |
+| M04 | 判定表 | {{state_change}}, {{sequence_event}} | generate-test-cases-blackbox |
+| M05 | 因果图 | {{error_message}}, {{error_handling}} | generate-test-cases-blackbox |
+| M06 | 场景法 | {{sequence_event}}, {{state_change}} | generate-test-cases-blackbox |
+| M07 | 功能图法 | {{state_change}}, {{sequence_event}} | generate-test-cases-blackbox |
+| M08 | 随机测试 | {{resource_usage}}, {{time_constraint}} | generate-test-cases-blackbox |
+| M09 | 猜错法 | {{error_message}}, {{error_handling}} | generate-test-cases-blackbox |
+| M10 | 正交试验法 | {{return_value}}, {{data_persistence}} | generate-test-cases-blackbox |
+| M11 | 组合测试法 | {{return_value}}, {{sequence_event}} | generate-test-cases-blackbox |
+| M12 | 蜕变测试法 | {{pass_criteria}}, {{precision_tolerance}} | generate-test-cases-blackbox |
+
+## B.2 White-box Methods (M13-M18)
+| Method ID | 方法名 | 证据锚点 | Route Skill |
+| --- | --- | --- | --- |
+| M13 | 控制流测试 | 路径编号 | generate-test-cases-whitebox |
+| M14 | 数据流测试 | DU对编号 | generate-test-cases-whitebox |
+| M15 | 程序变异 | 变异体编号 | generate-test-cases-whitebox |
+| M16 | 程序插桩 | 插桩点编号 | generate-test-cases-whitebox |
+| M17 | 域测试 | 域编号 | generate-test-cases-whitebox |
+| M18 | 符号求值 | 约束表达式编号 | generate-test-cases-whitebox |
+
+## Routing Rules
+1. Use Method ID (`Mxx`) as the only routing key.
+2. `M01-M12` route to `generate-test-cases-blackbox`.
+3. `M13-M18` route to `generate-test-cases-whitebox`.
+4. Unknown IDs should be recorded in `method_alignment_report.gaps`.
+
+## Backward Compatibility
+- If input methods are provided as plain method names, map them to Method IDs before routing.
+- Keep Chinese method names for readability in `case_summary`.

.github/skills/build-expected-results/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: build-expected-results
-description: "当需要将测试用例中的 expected_result_placeholder 展开为可度量预期成果时使用。"
+description: "当测试用例包含 expected_result_placeholder 时使用，将其展开为可验证、可量化、可判定通过/失败的预期成果集合。"
 ---
 
 # build-expected-results

.github/skills/decompose-test-items/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: decompose-test-items
-description: "当需要基于需求类型把需求文本分解为可执行的正常/异常测试项时使用。"
+description: "当已获得 requirement_type 后，需将需求文本拆解为可执行的正常/异常测试项并输出 coverage_analysis（覆盖率、缺口、补充建议）时使用。"
 ---
 
 # decompose-test-items
@@ -11,8 +11,7 @@ description: "当需要基于需求类型把需求文本分解为可执行的正
 ## 输入
 - user_requirement_text
 - requirement_type
-- recommended_test_methods（可选）
-- suggested_decompose_template（可选）
+- recommended_test_methods（可选，格式建议 `Mxx|方法名`）
 
 ## 输出
 - normal_test_items：完整、可执行的正常测试项列表。

.github/skills/format-output/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: format-output
-description: "当需要将测试项、测试用例、预期成果按统一格式输出时使用。"
+description: "当需将测试项、测试用例、预期成果统一整理为三段式 Markdown 输出时使用，要求正常/异常分组且编号追踪一致。"
 ---
 
 # format-output

.github/skills/generate-test-cases-blackbox/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: generate-test-cases-blackbox
+description: "当 recommended_test_methods 命中 M01-M12 时使用，按黑盒方法特征生成正常/异常测试用例并输出 method_alignment_report。"
+---
+
+# generate-test-cases-blackbox
+
+## 目标
+对输入测试项应用黑盒方法（M01-M12），生成可重复执行、可验证的测试用例。
+
+## 输入
+- normal_test_items
+- abnormal_test_items
+- requirement_type（可选）
+- recommended_test_methods（可选，格式建议 `Mxx|方法名`）
+
+## 输出
+- normal_test_cases
+- abnormal_test_cases
+- method_alignment_report
+
+## 黑盒方法范围
+- M01 功能分解
+- M02 等价类划分
+- M03 边界值分析
+- M04 判定表
+- M05 因果图
+- M06 场景法
+- M07 功能图法
+- M08 随机测试
+- M09 猜错法
+- M10 正交试验法
+- M11 组合测试法
+- M12 蜕变测试法
+
+## 通用规则
+1. 每个测试项至少绑定一个黑盒方法；高风险测试项建议绑定两种方法。
+2. `test_inputs` 必须反映方法特征（类编号、边界点、规则号、场景路径、组合强度、随机参数等）。
+3. `operation_steps` 必须体现方法步骤链，禁止空泛表述。
+4. `case_summary` 必须标注 `Mxx|方法名`。
+5. 每条用例应优先使用黑盒占位符：`{{return_value}}`、`{{state_change}}`、`{{error_message}}`。
+
+## 方法详细说明（M01-M12）
+- M01 功能分解：适用于规格说明可分层拆解的场景。先按功能抽象把程序分解为功能层次和最低层子功能，再按数据抽象为每个子功能的输入/输出取值集合设计数据。`test_inputs` 需显式包含子功能标识、前置依赖和数据抽象来源，`operation_steps` 按“分层覆盖 -> 子功能执行 -> I/O 校验”编写。
+- M02 等价类划分：在规格约束基础上划分有效等价类与无效等价类，并为每个等价类分配唯一编号。每条用例至少映射一个目标类，建议用“类编号+代表值+预期策略”组织 `test_inputs`。执行时应同时验证有效类的主功能正确性和无效类的错误处理一致性。
+- M03 边界值分析：先识别全部边界条件，再为每个边界给出满足边界和不满足边界的数据。建议采用 `L-1/L/L+1` 与 `U-1/U/U+1`，并对多维边界补充组合边界样本。预期结果需区分“计算错误”（边界内）和“域错误”（边界外），作为 `expected_results` 的判定要点。
+- M04 判定表：以“条件桩、条件条目、动作桩、动作条目”构建规则表，并将每一列规则转化为测试用例。适用前提包括：条件/规则顺序不影响操作、规则命中后无需再检验其他规则、多动作执行顺序无关。`operation_steps` 需记录规则命中过程，`expected_results` 需核验动作集合完整且无多执行。
+- M05 因果图：先识别原因（输入）与结果（输出）并编号，再构建因果关系和约束，随后转换为判定表并逐列生成用例。适用于输入组合关系复杂的需求；若因果图过大导致用例爆炸，应在 `gaps` 中说明并采用降级策略（如关键链路抽样）。用例中应保留原因/结果编号，保证可追踪。
+- M06 场景法：以用况路径为单位覆盖基本流与备选流，形成从开始到结束的可执行场景。步骤应包括：确定流、组合场景、设计用例、审验并去冗余、为用例补充测试数据。`operation_steps` 要体现场景触发条件和路径切换点，避免只写主流程。
+- M07 功能图法：使用“状态转移图 + 逻辑功能模型”联合建模。先在每个状态内用因果图/判定表生成局部用例，再由状态转移图导出路径用例，最后合成实用测试用例。`test_inputs` 需同时体现状态路径和状态内输入条件，`expected_results` 要同时验证迁移结果与局部逻辑输出。
+- M08 随机测试：在输入取值区间上随机取样，并在必要时约束随机分布与种子以保证可复现。该方法在预期输出难以精确构造时更常用于可靠性测试和强度测试。`method_alignment_report` 需包含采样范围、分布、样本量和失败样本聚类结论。
+- M09 猜错法：由有经验测试人员基于历史缺陷和易错情况表设计用例。适合补齐规格难覆盖的风险点（如空值、边界格式、异常时序、重复操作）。用例应明确“猜错依据”，并在结果中验证防护是否生效。
+- M10 正交试验法：把影响功能实现的操作对象和外部因素作为因子，把因子取值作为水平，构造因素分析表并选用正交表进行代表性组合。目标是在减少用例规模的同时保持较高覆盖效率。建议在 `test_inputs` 中保留因子-水平映射，便于回归和复现。
+- M11 组合测试法：面向多参数输入生成组合用例集，并按组合强度评估覆盖充分性。常见强度包括单一选择、基本选择、成对组合、全组合和 K 强度组合。黑盒场景中组合参数通常是外部输入，需在用例中标注强度等级和约束条件。
+- M12 蜕变测试法：适用于单个用例预期结果难判定的场景。通过构造蜕变关系验证“源用例与跟随用例”的结果是否满足关系；不满足即判定失败。该方法可与其他方法联合：既可用于结果验证，也可生成补充用例。
+
+## 对齐输出要求
+- 在 `method_alignment_report` 中记录：`case_id`、`selected_methods`、`alignment_score`、`gaps`、`fix_suggestions`。
+- 无法落地的方法必须进入 `gaps` 并提供可执行修复建议。

.github/skills/generate-test-cases-whitebox/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: generate-test-cases-whitebox
+description: "当 recommended_test_methods 命中 M13-M18 时使用，按路径/数据/变异/插桩证据链生成可追踪测试用例并输出 method_alignment_report。"
+---
+
+# generate-test-cases-whitebox
+
+## 目标
+对输入测试项应用白盒方法（M13-M18），生成带可追踪执行证据的测试用例。
+
+## 输入
+- normal_test_items
+- abnormal_test_items
+- requirement_type（可选）
+- recommended_test_methods（可选，格式建议 `Mxx|方法名`）
+
+## 输出
+- normal_test_cases
+- abnormal_test_cases
+- method_alignment_report
+
+## 白盒方法范围
+- M13 控制流测试
+- M14 数据流测试
+- M15 程序变异
+- M16 程序插桩
+- M17 域测试
+- M18 符号求值
+
+## 通用规则
+1. 白盒用例必须包含证据锚点（路径编号、DU对、变异体、插桩点、域编号、约束编号）。
+2. `test_inputs` 应能触发目标证据链，禁止只描述功能输入。
+3. `operation_steps` 必须包含证据采集或比对动作。
+4. `case_summary` 必须标注 `Mxx|方法名`。
+5. 白盒用例可结合 `{{pass_criteria}}`、`{{resource_usage}}`、`{{state_change}}` 进行结果绑定。
+
+## 方法详细说明（M13-M18）
+- M13 控制流测试：依据控制流图生成用例，目标是覆盖不同控制结构。常用覆盖包括语句覆盖、分支覆盖、条件覆盖、条件组合覆盖、MC/DC 和路径覆盖。标准步骤为：流程图转控制流图、路径表达式求解、路径树生成、路径编码与译码、按目标路径枚举测试用例。`method_alignment_report` 应记录覆盖准则与未覆盖路径原因。
+- M14 数据流测试：在控制流图上分析变量定义、使用和消除，重点发现“未定义就使用”与“定义后未使用”等数据流异常。建议步骤为：构建控制流图、标注链路数据操作符、选择数据流覆盖策略、导出测试路径、再生成输入与用例。除静态分析外，可结合动态数据流检查提高真实性，但要说明路径覆盖局限。
+- M15 程序变异：以错误驱动方式定义变异算子并生成语法合法的变异体，通过测试数据逐个执行变异体判断检测能力。可区分强变异与弱变异，并在报告中统计“杀死率、存活率、等价变异占比”。该方法既用于找缺陷，也用于评价现有测试用例集的有效性。
+- M16 程序插桩：通过在程序中插入观测操作实现证据采集，但不得改变被测程序原有功能与运行语义。建议步骤为：定位插桩点、插入采样逻辑、执行测试、回收与分析数据、移除或关闭插桩。由于数据记录量通常较大，宜借助工具完成并在报告中注明插桩开销与可信度。
+- M17 域测试：目标是验证程序对输入空间划分是否正确，重点检查域内、边界和跨域样本的判定一致性。该方法约束较多、使用门槛较高，通常用于有特殊质量要求的场景。用例中应保留域划分依据与判定规则，避免仅给样本值不说明域归属。
+- M18 符号求值：允许变量取符号值，通过符号执行检查公式与分支约束是否满足预期，并可导出程序路径用于生成测试数据。适用于公式密集或约束明确的逻辑。复杂分支推荐工具化处理，分支较少时可人工推导并在用例中记录约束来源与推导过程。
+
+## 对齐输出要求
+- 在 `method_alignment_report` 中记录：`case_id`、`selected_methods`、`alignment_score`、`gaps`、`fix_suggestions`。
+- 对无法构造证据链的方法，必须输出 `gaps` 与降级策略说明。

.github/skills/generate-test-cases/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: generate-test-cases
-description: "当需要根据已分解测试项生成包含操作步骤与测试内容的具体测试用例时使用。"
+description: "当已有 normal/abnormal 测试项且需按统一规范生成可执行测试用例时使用；不负责测试方法选择，输出测试用例与合规校验报告。"
 ---
 
 # generate-test-cases
@@ -12,12 +12,11 @@ description: "当需要根据已分解测试项生成包含操作步骤与测试
 - normal_test_items
 - abnormal_test_items
 - requirement_type（可选）
-- recommended_test_methods（可选）
 
 ## 输出
 - normal_test_cases
 - abnormal_test_cases
-- method_alignment_report
+- case_compliance_report
 
 每条测试用例必须包含：
 - case_id
@@ -39,12 +38,24 @@ description: "当需要根据已分解测试项生成包含操作步骤与测试
 3. 必须区分正常测试用例与异常测试用例。
 4. 操作步骤应可顺序执行，避免歧义。
 5. 操作步骤必须包含明确动作、对象和输入条件，禁止笼统动作词。
-6. test_content 必须包含可验证条件，便于后续生成可度量预期成果。
+6. `case_summary` 与 `evaluation_criteria` 必须包含可验证条件，便于后续生成可度量预期成果。
 7. 测试用例应符合可重复执行原则，初始条件和参数必须可复现。
 8. 测试输入必须标识有效值/无效值/边界值性质、输入来源、真实或模拟属性及事件顺序。
 9. 每个操作步骤应包含测试输入、动作、中间期望、评估准则与异常终止信号。
 10. pass_criteria 必须明确是否通过的判定条件，禁止模糊描述。
 
+## 统一生成规范（与测试方法无关）
+1. 字段完整性：每条用例必须包含本 Skill 规定的全部字段，缺失字段不得省略，应给出“待补充”占位。
+2. 可执行性：`operation_steps` 必须按可顺序执行的步骤组织，单步只表达一个核心动作，避免多动作混写。
+3. 可复现性：`initialization_requirements`、`test_inputs`、`preconditions_constraints` 必须足以让第三方复现实验。
+4. 可观测性：每条步骤必须关联可观测结果或中间检查点，避免只描述操作不描述观测。
+5. 可判定性：`evaluation_criteria` 与 `pass_criteria` 必须给出明确判定阈值或布尔条件，禁止模糊词。
+6. 异常完备性：异常用例必须包含异常触发条件、预期保护动作、终止条件与恢复后状态要求。
+7. 去歧义：字段中禁止“适当”“正常”“合理”等无量纲表述，需替换为可验证条件。
+8. 去重一致性：相同测试项下语义重复的用例应合并，保留最完整版本并保证编号稳定。
+9. 追踪关系：`test_traceability` 必须指向来源测试项，保证“测试项 -> 测试用例”可追踪。
+10. 结果衔接：`expected_result_placeholder` 必须可直接用于下一步预期成果展开，不得出现不可映射占位符。
+
 ## expected_result_placeholder 映射（用于 Step 4 展开）
 - {{return_value}}：接口或函数返回值验证。
 - {{state_change}}：系统状态变化验证。
@@ -59,30 +70,6 @@ description: "当需要根据已分解测试项生成包含操作步骤与测试
 - {{resource_usage}}：资源占用与空间约束验证。
 - {{pass_criteria}}：用例通过准则验证。
 
-## 常用测试方法应用清单（B.1.1-B.2.6）
-每个用例必须在 summary 中标注所用方法，并在 steps 中体现方法特征。
-
-| 方法 | 适用场景 | 输入构造规则 | 步骤设计特征 |
-| --- | --- | --- | --- |
-| 功能分解 | 功能/接口主流程 | 按子功能拆输入集 | 用例按子功能逐级覆盖 |
-| 等价类划分 | 功能/接口/边界 | 有效类与无效类分别取代表值 | 每类至少一条步骤 |
-| 边界值分析 | 输入输出边界 | 取边界、邻近、越界值 | 连续执行边界点序列 |
-| 判定表 | 多条件组合逻辑 | 依据条件桩生成规则列 | 一列规则对应一条步骤流 |
-| 因果图 | 条件与结果耦合 | 构建原因-结果及约束 | 覆盖关键因果链路 |
-| 场景法 | 事件驱动流程 | 基本流与备选流输入 | 按场景路径组织步骤 |
-| 功能图法 | 状态与逻辑联合 | 状态转移输入序列 | 状态路径+局部逻辑组合 |
-| 随机测试 | 可靠性/强度 | 输入区间+概率分布 | 指定随机规则和样本量 |
-| 猜错法 | 高风险经验缺陷 | 构造易错输入集合 | 直接验证高风险点 |
-| 正交试验法 | 多因子组合优化 | 因子-水平表+正交表 | 覆盖代表组合点 |
-| 组合测试法 | 参数组合覆盖 | 选定组合强度（pairwise/K） | 按组合强度生成步骤 |
-| 蜕变测试法 | 预期结果难判定 | 构造蜕变关系输入组 | 校验用例间关系一致性 |
-| 控制流测试 | 白盒流程覆盖 | 按路径目标构造输入 | 步骤对应语句/分支路径 |
-| 数据流测试 | 白盒变量使用 | 定义-使用链路输入 | 覆盖关键定义引用对 |
-| 程序变异 | 错误驱动验证 | 针对变异体生成输入 | 验证是否杀死变异体 |
-| 程序插桩 | 运行行为观测 | 插桩点对应输入 | 步骤包含采样与比对 |
-| 域测试 | 输入空间划分检验 | 构造域边界/域内样本 | 验证域划分正确性 |
-| 符号求值 | 公式与路径推导 | 依据符号约束反推输入 | 校验符号关系与结果 |
-
 ## 禁止模糊描述
 - 错误示例："检查功能正常"；正确示例："验证返回状态码为200且响应体包含status=success"。
 - 错误示例："输入合法数据"；正确示例："在用户名输入框输入长度为8的字母数字字符串并提交"。
@@ -92,5 +79,5 @@ description: "当需要根据已分解测试项生成包含操作步骤与测试
 - 每条用例必须可在下一步绑定一条明确、可验证的预期成果。
 - 每条 expected_result_placeholder 必须可映射到定量或可观察的检查项。
 
-## 对齐校验
-- 输出 method_alignment_report，至少包含：case_id、selected_methods、alignment_score、gaps、fix_suggestions。
+## 合规校验输出
+- 输出 case_compliance_report，至少包含：case_id、completeness_score、executability_score、ambiguity_flags、gaps、fix_suggestions。

.github/skills/identify-requirement-type/SKILL.md

@@ -1,12 +1,12 @@
 ---
 name: identify-requirement-type
-description: "当需要在测试项分解与测试用例生成之前识别需求类型时使用。"
+description: "当输入为原始需求文本且需判定测试需求主类型（含未知回退）、候选类型与推荐方法ID（Mxx|方法名）时使用。"
 ---
 
 # identify-requirement-type
 
 ## 目标
-将用户需求文本识别为明确的测试需求类型，为后续测试项分解与测试用例生成提供分类依据、推荐测试方法与分解模板。
+将用户需求文本识别为明确的测试需求类型，为后续测试项分解与测试用例生成提供分类依据与推荐测试方法。
 
 ## 输入
 - user_requirement_text：用户原始需求文本。
@@ -31,8 +31,7 @@ description: "当需要在测试项分解与测试用例生成之前识别需求
   - 未知类型
 - reason：简要判断依据。
 - candidates：当 requirement_type 为未知类型时，给出 1-3 个最接近候选类型。
-- recommended_test_methods：基于类型推荐的测试方法列表（按优先级排序）。
-- suggested_decompose_template：推荐的测试项分解模板名称。
+- recommended_test_methods：基于类型推荐的测试方法列表（按优先级排序），格式为 `Mxx|方法名`。
 - type_signals：触发该类型判断的关键语义信号。
 
 ## 类型识别信号
@@ -51,24 +50,24 @@ description: "当需要在测试项分解与测试用例生成之前识别需求
 - 敏感性测试：关注有效输入类中可能引发不稳定或不正常处理的数据组合。
 - 测试充分性要求：关注需求覆盖率、配置项覆盖、语句覆盖、分支覆盖及未覆盖分析确认。
 
-## 附录 A：类型到方法与模板映射
-| 需求类型 | 推荐测试方法（优先顺序） | 推荐分解模板 |
-| --- | --- | --- |
-| 功能测试 | 功能分解, 等价类划分, 边界值分析, 场景法 | functional-standard-template |
-| 性能测试 | 边界值分析, 组合测试法, 随机测试, 正交试验法 | performance-metric-template |
-| 外部接口测试 | 等价类划分, 边界值分析, 判定表, 因果图 | external-interface-template |
-| 人机交互界面测试 | 场景法, 猜错法, 等价类划分, 边界值分析 | hmi-flow-template |
-| 强度测试 | 随机测试, 组合测试法, 边界值分析 | stress-limit-template |
-| 余量测试 | 边界值分析, 组合测试法 | margin-capacity-template |
-| 可靠性测试 | 随机测试, 场景法, 组合测试法, 蜕变测试法 | reliability-profile-template |
-| 安全性测试 | 边界值分析, 场景法, 猜错法, 因果图 | safety-hazard-template |
-| 恢复性测试 | 场景法, 功能图法, 猜错法 | recovery-fault-template |
-| 边界测试 | 边界值分析, 等价类划分, 组合测试法 | boundary-focused-template |
-| 安装性测试 | 场景法, 猜错法 | install-config-template |
-| 互操作性测试 | 场景法, 组合测试法, 因果图 | interoperability-template |
-| 敏感性测试 | 组合测试法, 正交试验法, 随机测试, 猜错法 | sensitivity-combination-template |
-| 测试充分性要求 | 控制流测试, 数据流测试, 程序变异, 程序插桩 | adequacy-coverage-template |
-| 未知类型 | 功能分解, 等价类划分, 边界值分析 | generic-fallback-template |
+## 附录 A：类型到方法映射
+| 需求类型 | 推荐测试方法（优先顺序，方法ID+中文名） |
+| --- | --- |
+| 功能测试 | M01|功能分解, M02|等价类划分, M03|边界值分析, M06|场景法, M04|判定表, M05|因果图, M11|组合测试法, M09|猜错法 |
+| 性能测试 | M03|边界值分析, M11|组合测试法, M10|正交试验法, M08|随机测试, M06|场景法, M07|功能图法, M16|程序插桩 |
+| 外部接口测试 | M02|等价类划分, M03|边界值分析, M04|判定表, M05|因果图, M11|组合测试法, M06|场景法, M09|猜错法 |
+| 人机交互界面测试 | M06|场景法, M09|猜错法, M02|等价类划分, M03|边界值分析, M11|组合测试法, M04|判定表 |
+| 强度测试 | M08|随机测试, M11|组合测试法, M03|边界值分析, M10|正交试验法, M06|场景法, M16|程序插桩 |
+| 余量测试 | M03|边界值分析, M11|组合测试法, M06|场景法, M10|正交试验法, M08|随机测试 |
+| 可靠性测试 | M08|随机测试, M06|场景法, M11|组合测试法, M12|蜕变测试法, M09|猜错法, M16|程序插桩, M07|功能图法 |
+| 安全性测试 | M03|边界值分析, M06|场景法, M09|猜错法, M05|因果图, M04|判定表, M11|组合测试法, M07|功能图法 |
+| 恢复性测试 | M06|场景法, M07|功能图法, M09|猜错法, M11|组合测试法, M04|判定表, M16|程序插桩 |
+| 边界测试 | M03|边界值分析, M02|等价类划分, M17|域测试, M11|组合测试法, M04|判定表, M06|场景法 |
+| 安装性测试 | M06|场景法, M09|猜错法, M11|组合测试法, M02|等价类划分, M03|边界值分析 |
+| 互操作性测试 | M06|场景法, M11|组合测试法, M05|因果图, M04|判定表, M07|功能图法, M09|猜错法 |
+| 敏感性测试 | M11|组合测试法, M10|正交试验法, M08|随机测试, M09|猜错法, M03|边界值分析, M12|蜕变测试法 |
+| 测试充分性要求 | M13|控制流测试, M14|数据流测试, M15|程序变异, M16|程序插桩, M17|域测试, M18|符号求值, M11|组合测试法 |
+| 未知类型 | M01|功能分解, M02|等价类划分, M03|边界值分析, M06|场景法, M11|组合测试法, M09|猜错法 |
 
 ## 规则
 1. 优先依据需求文本中的显式表述进行分类。
@@ -77,13 +76,14 @@ description: "当需要在测试项分解与测试用例生成之前识别需求
 4. 判断依据需简洁、可追溯到文本证据。
 5. 若需求同时覆盖多个类型，输出主类型 requirement_type，并将次类型放入 candidates。
 6. recommended_test_methods 至少返回 2 个方法，优先返回文档中可直接执行的方法。
-7. suggested_decompose_template 必须与 requirement_type 一致。
+7. 方法标识以 Method ID（Mxx）为路由主键，中文方法名仅用于可读性展示。
 
 ## 容错
 - 当需求描述过于笼统或跨多类型混合时，输出未知类型，并在 candidates 给出最接近类型。
 - 当识别不稳定时，优先保守分类，不强行归入单一类型。
 - 未知类型不阻断后续流程，应继续执行通用测试项分解。
 - 当文本信息不足以支持白盒方法推荐时，保留黑盒优先推荐并标记 reason。
+- 当仅能识别到中文方法名时，先映射为 Method ID 后再输出。
 
 ## 调试
 - debug 模式下返回每个类型的分类分数 classification_scores。

.github/skills/testing-orchestrator/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: testing-orchestrator
-description: "当用户要求测试项分解或测试用例生成且需要完整工具调用链时使用。"
+description: "当需要从需求文本一键生成测试项、测试用例与预期成果时使用，按 identify→decompose→generate→build→format 全链路编排并透传上下文。"
 ---
 
 # testing-orchestrator
@@ -31,15 +31,13 @@ description: "当用户要求测试项分解或测试用例生成且需要完整
 	- requirement_type
 	- reason
 	- candidates
-	- recommended_test_methods
-	- suggested_decompose_template
+	- recommended_test_methods（格式：`Mxx|方法名`）
 
 ### Step 2: decompose-test-items
 - 输入：
 	- user_requirement_text
 	- requirement_type（来自 Step 1）
 	- recommended_test_methods（来自 Step 1）
-	- suggested_decompose_template（来自 Step 1）
 - 输出：
 	- normal_test_items
 	- abnormal_test_items
@@ -56,6 +54,13 @@ description: "当用户要求测试项分解或测试用例生成且需要完整
 	- abnormal_test_cases
 	- method_alignment_report
 
+#### Step 3 路由规则（按需调用）
+1. 从 `recommended_test_methods` 提取 Method ID（`Mxx`）。
+2. 若命中 `M01-M12`，调用 `generate-test-cases-blackbox`。
+3. 若命中 `M13-M18`，调用 `generate-test-cases-whitebox`。
+4. 同一测试项命中黑盒+白盒时，并行生成后去重合并。
+5. 合并后统一输出 `case_id` 与 `method_alignment_report`，并记录未落地方法到 `gaps`。
+
 ### Step 4: build-expected-results
 - 输入：
 	- normal_test_cases（来自 Step 3）