test-report-review

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、技术或原始质量事实冲突。

执行流程

1. 读取 prompts/test-report-review.md，按完整规范执行。
2. 建立输入清单，记录每个来源的标识、版本、责任角色和是否可读；未提供版本时写 not supplied，不得猜测。
3. 将报告结论逐项与执行证据、缺陷证据、已测/未测范围、角色报告和项目行动对齐。
4. 单列矛盾、隐藏或未知范围、残余风险、条件和开放行动，保留各自来源。
5. 依据阻塞项和条件项给出 pass、conditional_pass 或 reject 的 AI 辅助建议。
6. 交付前检查证据边界、来源版本、责任人和 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，却没有责任人/未分配状态、关闭门槛和验证证据。

交付前自检

• 执行证据和缺陷证据的有无及版本已明确
• 报告结论、范围、统计和门禁均已与原始证据核对
• 矛盾、未测范围、残余风险和开放行动均可见
• 每个条件有责任人或 unassigned、关闭门槛与验证证据
• PM 输入没有覆盖质量事实
• 建议符合规则，且 human_final_decision: pending