针对测试用例生成添加了常用测试方法；更新了需求提取工具

.github/AGENTS.md

@@ -3,22 +3,66 @@
 ## 适用范围
 - 本工作区包含基于 Tool Calling 与 Skill Calling 的测试内容生成链路。
 - 当用户提出测试项分解、测试用例生成或预期成果生成需求时，必须触发 testing-orchestrator。
+- 本约定用于约束技能间数据传递、输出结构与容错策略。
 
 ## 已注册技能
-- identify-requirement-type：将用户需求文本识别为明确的测试需求类型，为后续测试项分解与测试用例生成提供分类依据。
-- decompose-test-items：按需求类型规则生成正常测试与异常测试测试项。
-- generate-test-cases：按测试项生成可执行测试用例，至少 1 条/测试项。
-- testing-orchestrator：按标准顺序编排工具调用并输出结构化结果。
+- identify-requirement-type：将需求文本识别为测试需求类型，并给出推荐测试方法。
+- decompose-test-items：按需求类型分解为可执行的正常/异常测试项，并输出覆盖分析。
+- generate-test-cases：按测试项生成结构化测试用例，覆盖测试用例要素。
+- build-expected-results：将测试用例中的预期占位符展开为可度量预期成果。
+- format-output：将测试项、测试用例、预期成果整理为统一三段式输出。
+- testing-orchestrator：按标准顺序编排技能并管理上下文传递。
 
 ## 强制调用链
 1. identify-requirement-type
 2. decompose-test-items
 3. generate-test-cases
-4. build_expected_results
-5. format_output
+4. build-expected-results
+5. format-output
 
-## 约束规则
+## 步骤输入输出契约
+
+### Step 1: identify-requirement-type
+- 输入：user_requirement_text
+- 输出：requirement_type, reason, candidates, recommended_test_methods, suggested_decompose_template
+
+### Step 2: decompose-test-items
+- 输入：user_requirement_text, requirement_type, recommended_test_methods, suggested_decompose_template
+- 输出：normal_test_items, abnormal_test_items, coverage_analysis
+
+### Step 3: generate-test-cases
+- 输入：normal_test_items, abnormal_test_items, requirement_type, recommended_test_methods
+- 输出：normal_test_cases, abnormal_test_cases, method_alignment_report
+
+### Step 4: build-expected-results
+- 输入：normal_test_cases, abnormal_test_cases, requirement_type, recommended_test_methods
+- 输出：normal_expected_results, abnormal_expected_results
+
+### Step 5: format-output
+- 输入：normal_test_items, abnormal_test_items, normal_test_cases, abnormal_test_cases, normal_expected_results, abnormal_expected_results, coverage_analysis
+- 输出：三段式结构化 Markdown
+
+## 全局约束规则
 - 除非用户明确要求只看中间步骤，否则禁止跳步。
 - 每一步都必须显式接收上一步输出作为上下文输入。
-- 若无法识别类型，必须输出未知类型及候选类型，并继续执行通用分解。
+- 若 requirement_type 为未知类型，必须继续执行通用分解，不得中断调用链。
+- 每个测试项必须同时覆盖正常与异常视角；复杂功能必须细分到可直接对应测试用例的粒度。
+- 每个测试项、测试用例、预期成果必须具备唯一标识，并保持可追踪映射关系。
 - 最终输出必须严格包含测试项、测试用例、预期成果三段，并按正常测试/异常测试分组。
+- 测试项和测试用例设计必须对齐以下规范：
+	- 测试项分解要求
+	- 测试项与测试用例技术要求
+	- 常用测试方法
+
+## 失败降级策略
+| 失败场景 | 处理策略 | 是否继续 |
+| --- | --- | --- |
+| Step 1 无法稳定识别类型 | requirement_type=未知类型，输出 1-3 个候选类型 | 是 |
+| Step 2 覆盖率不足 | 输出 coverage_analysis 与补充建议 | 是 |
+| Step 3 方法不完全对齐 | 输出 method_alignment_report 并标记低对齐项 | 是 |
+| Step 4 缺少可量化指标 | 使用通用默认口径并标记待确认字段 | 是 |
+| Step 5 格式化失败 | 回退为结构化 JSON 输出，不得丢失三段内容 | 是 |
+
+## 调试模式
+- debug=true 时，每一步追加 step_name, input_summary, output_summary, success, fallback_used, duration_ms。
+- debug=true 时，最终输出追加覆盖矩阵与方法追踪矩阵。