用途：在真实项目中处理测试报告相关任务，产出一份可直接用于执行、评审或跟进的结果。触发场景包括“测试报告”和 test reporting。
主要能力：生成包含摘要、指标、缺陷分析和风险评估的测试报告；默认输出 Markdown，用户指定时可切换其他格式；支持 Excel、CSV、JSON、Word 等格式（需读取 output-formats.md）；可套用 output-templates/ 中的现成模板；可参考 examples/ 中的样例。
使用方式：执行前必须阅读并遵循 prompts/test-reporting.md 中的主提示词，覆盖清单、输出结构和质量要求。只补充真正影响结果的项目上下文，如范围、环境、限制、风险、依赖和期望产出。信息不全时先给可用初版，并显式标出假设与信息缺口。需要深资料时只读 references/ 中相关文件；需要格式转换或校验时优先使用 scripts/ 中已有脚本；需要评测或回归时使用 evals/ 并用 skill-up 校验运行；只要最短上手路径时读 quick-start.md。
核心约束：按风险或业务影响排优先级，不平均摊铺；把已确认事实与当前假设分开写；将已确认事实、推断、缺失证据、残余风险和建议分成可辨识的独立部分；不编造用户未提供的接口、字段、环境或根因细节；结果必须可执行，场景具体、有优先级、能指导下一步。执行证据和缺陷证据同时缺失时，整体质量状态只能是 not executed or insufficient evidence，不能报告通过或具备发布条件。
交付前自检：遵循主提示词输出结构；覆盖已测范围、未测范围、整体状态、关键缺陷或阻塞项、风险总结、覆盖信心、环境或数据问题、发布建议等最低关注项；高风险项有明确优先级；假设与信息缺口已标明；证据层级分开，计划、环境就绪或角色观点不被当成执行通过证据；缺执行与缺陷证据时不生成通过、零缺陷或可发布结论。
常见误区：范围与上下文不清时不要假装完整可用；不要把所有项写成同等重要；不要跳过假设与信息缺口；不要把计划执行数写成实际执行数，也不要把缺陷清单缺失写成零缺陷；不要输出与当前工具链无关的空泛理论。