| name | test-report-review |
| description | Use this skill when a test report needs an evidence-consistency review before Human approval; triggers include 测试报告评审、质量报告审核、测试结论复核, test report review and test evidence review. |
测试报告评审
目标
对测试报告、原始证据、范围、角色报告和项目行动做一致性核对，形成可追溯的 AI 辅助建议。只评审已提供材料；Human 保留最终决定权。
何时使用
- 测试报告声称通过、可发布或满足门禁，需要核对原始执行与缺陷证据。
- 需要暴露未测范围、证据矛盾、残余风险或未关闭行动。
- 排期或管理意见可能与 QA、技术或原始质量事实冲突。
执行流程
- 读取 prompts/test-report-review.md，按完整规范执行。
- 建立输入清单，记录每个来源的标识、版本、责任角色和是否可读；未提供版本时写
not supplied，不得猜测。
- 将报告结论逐项与执行证据、缺陷证据、已测/未测范围、角色报告和项目行动对齐。
- 单列矛盾、隐藏或未知范围、残余风险、条件和开放行动，保留各自来源。
- 依据阻塞项和条件项给出
pass、conditional_pass 或 reject 的 AI 辅助建议。
- 交付前检查证据边界、来源版本、责任人和 Human 最终决定状态。
不可破坏的规则
- 执行证据与缺陷证据同时缺失时，状态必须为 未执行或证据不足，建议必须为
reject；报告摘要、角色意见或排期不能把它改写为通过。
- 80/80、100% 等统计只证明其明确对应的执行范围，不得外推到未测、遗漏或版本不明的范围。
- PM 输入只提供排期、资源、依赖、责任和行动状态；不得改变执行结果、缺陷等级/状态、质量事实、风险或 Human 决定。
- 每个结论引用来源及版本；冲突未获授权解决时保留双方，不自行选择对项目更有利的一方。
- 输出始终是 AI 辅助建议，并保持
human_final_decision: pending；不得声称已批准、已放行或已接受风险。
建议规则
reject：存在阻塞项，例如无可评审报告、执行与缺陷证据同时缺失、关键未测范围被隐藏、开放 P0/P1、关键结论与原始证据冲突，或质量事实被无权覆盖。conditional_pass：无阻塞项，但存在范围明确、责任与关闭门槛可追踪、关闭证据可验证的非阻塞条件。pass：报告与原始证据一致，无阻塞项或条件项；可保留不影响建议的改进项。
不得按发现数量投票，也不得用正向证据抵消一个关键阻塞项。
输出要求
依次输出：评审状态、来源与版本、证据一致性矩阵、已测与未测范围、矛盾、阻塞项与条件项、残余风险、开放行动、建议依据与限制、Human 待决问题。无内容的必需章节明确写“无”，不要省略。
按需加载
- 每次执行均读取
prompts/test-report-review.md；它是完整、可独立运行的评审规范。
- 本 Skill 不依赖其他 Skill、项目路径或数据库对象。角色报告缺失时按输入缺口处理，不尝试读取别的 Skill 私有文件。
常见误区
- 把报告中的“全部通过”当成原始执行证据。
- 只列已测数量，不列批准排除、未知范围和隐藏未测项。
- 把
fixed 当成 verified，或把无缺陷记录当成无缺陷。
- 因发布日期临近而改写失败结果、缺陷等级或风险。
- 给出
conditional_pass，却没有责任人/未分配状态、关闭门槛和验证证据。
交付前自检
