用途：在 delivery-loop（frontend-/backend-/fullstack-delivery-loop）到达边界（测试通过、评审干净、可上线）或用户希望诊断停滞时，把整次运行转化为有证据支撑的复盘报告。报告不是给人看的总结，而是 skill-evolution-factory 的输入，用于改动循环技能与人设文件中的关键指令并度量差异，因此每条批评都要指向具体文件与具体指令。
角色：使用者是分析者而非编排者，需从证据重建运行过程、诚实评判，并交出一份值得度量的改动清单。
输出：每次运行一份 Markdown 报告。先按顺序解析写入位置：若 ${CLAUDE_PLUGIN_ROOT}/docs/feedbackloops/ 存在则写这里；否则写入 <host-repo>/docs/feedbackloops/ 并告知用户未找到开发检出目录。目录缺失时创建。文件名格式：<YYYY-MM-DD>-<loop>-<change-slug>-<session8>.md。
使用方式：第一步先跑收集器（在宿主仓库根目录）： python3 "${CLAUDE_PLUGIN_ROOT}/.claude/skills/delivery-loop-retro/scripts/collect_trace.py" 可加 --session <id> 针对历史运行，--json 输出原始摘要，--help 查看参数。将其 Markdown Trace index 原样粘贴进报告附录。收集器只做确定性统计，判断仍需结合 transcript、子代理返回内容、agent-memory 片段与 OpenSpec 变更/保管库产物。
主要能力：沿“做对了什么及原因”、“出了什么问题”、“摩擦与浪费（按事件归因并量化成本）”、“代理协作”等维度评判；每个负面问题转成给 skill-evolution-factory 的改进目标表格，列含症状与成本、目标文件、章节/关键行、可证伪的改动建议（以引用文本为锚）、证据。
限制与质量要求：结论必须有证据（派发、片段、发现或 transcript 时刻）；摩擦需带 token、工具调用、时长或往返次数；改进目标须写明文件与指令；对干净部分应诚实保护，不编造问题。目标须在真实文件内引用现有指令，避免提出已存在的内容。文件包括 scripts/collect_trace.py、references/evidence-sources.md、references/report-template.md。其他如定价、平台等资料暂未提供。