技能提升网一个 PR 修改了认证、账单和通知三个模块，描述里只写“完成账户升级需求”。CI全部通过，但评审人找不到退款失败路径对应的测试，也说不清通知模块为什么被改。
绿色检查只能证明已配置的任务通过，不能证明需求全覆盖或改动都合理。合并门禁要建立三方对应关系，并把空白格当成需要解释的证据缺口。
把需求拆到可验证条款
从 Issue、验收标准和设计决定中提取编号、触发条件、预期行为和异常处理。含糊的“支持升级”不能直接映射代码，需要先确认成功、失败、权限、边界和回退行为。
追踪矩阵要允许三种异常
| 异常 | 示例 | 门禁动作 |
|---|---|---|
| 需求无实现 | 验收条款找不到对应改动 | 退回补实现或澄清范围 |
| 实现无需求 | 修改了额外模块或行为 | 解释必要性或拆分PR |
| 实现无测试 | 代码存在但无可验证用例 | 补正向、边界或失败测试 |
| 测试无结果 | 用例存在但CI未运行或失败 | 阻止合并 |
行可以按需求条款展开，列出涉及文件、测试用例、执行结果和评审状态。不要只给覆盖率百分比。
未解决评论也是门禁输入
评论被标记解决不代表问题真的关闭。对涉及安全、数据迁移、兼容性和需求范围的评论，记录答复证据与最终处理。CI例外、跳过测试和手工验证也要显式说明。
先定义一条可复查的工作记录
开始处理前就确定如何编号输入、记录假设和保存人工修改。否则模型给出的候选项即使有用，也很难在审批时说明它来自哪一版资料。 对本任务，首轮只验证能否可靠支持这一判断：可以合并、需要补测试、需要拆分还是退回补需求证据。
角色：负责合并门禁的开发负责人或代码评审者。
触发：一个 PR 同时修改多个模块，描述声称完成需求但测试和验收关联不清。
资料：PR 差异、Issue 或需求条款、测试用例与结果、CI 状态、未解决评论。
判断：可以合并、需要补测试、需要拆分还是退回补需求证据。
交付：需求到代码到测试的追踪矩阵和合并门禁结论。
要求：逐条列出证据、未知项、规则冲突和需要谁确认，不执行任何高风险写入。
把正常项也纳入质量检查
| 能力步骤 | 接收资料 | 交给下一步 |
|---|---|---|
| 读取 PR、Issue、检查状态和未解决评论 | 仓库、PR、Issue 和 CI | 改动范围、关联与阻塞项 |
| 把需求条款映射到正向、反向、边界和异常测试 | 需求条款和现有测试 | 覆盖关系和缺失用例 |
异常清单通常最受关注，但正常项决定了是否存在漏检。按来源、时间和业务类型抽样回查，比较不同群组的错误分布，不要只用一个整体准确率掩盖局部问题。 验收终点应是可以交接的需求到代码到测试的追踪矩阵和合并门禁结论。
不要让异常在流程里静默通过
- 关键文件缺少版本、时间范围或唯一编号，无法确认是否属于同一任务
- 多个资料来源给出冲突事实，且没有被授权的基准可以裁决
- 结果会触发付款、权限、合同、生产、薪酬或对外承诺等高风险动作
- 可能造成的后果是未覆盖需求或无关改动进入主干，后续缺陷无法追溯责任和测试缺口
停止自动处理不等于停止工作。保留已经完成的证据整理，标出阻塞位置、责任人和期望回复时间，让人工从明确节点接手并继续完成需求到代码到测试的追踪矩阵和合并门禁结论。
Skill可以读和生成，不能替你点合并
Github Skill负责读取PR、Issue、检查状态和未解决评论；QA Req2Testcase Generator Skill负责把需求条款映射到正向、反向、边界和异常测试。两项能力的输出要前后衔接，不能只把同一份材料重复总结。
读取和生成覆盖矩阵可自动化，提交评论、修改 PR 或合并代码属于外部写入，必须由仓库权限持有人确认。
