用途：对刚完成的工作进行复盘，理解哪里出错、哪里耗时过长、哪里浪费了 token 或精力、出现了哪些死胡同、哪些做法有效，以及下次应改变什么。目标不只是罗列错误，而是找出根因并提出能提升未来表现的改动。
适用时机：用户要求做 retro、回顾哪里出错、分析任务为何耗时过长、找出低效或浪费、理解重复失败模式、改进下次工作流时启用。
复盘输入：聊天记录、用户指令、所用技能、仓库或任务上下文、工具行为、决策顺序；必要时也看错误输出、重试、被放弃的方案、不清晰的交接、任务中用户意图的变化。
交互方式：若失败模式已清晰，可直接产出复盘；若原因含糊、有争议、涉及情绪或需要更多操作者洞察，则先进行简短的迭代式复盘，提少量聚焦问题，再据此完善根因分析并产出最终复盘。问题应围绕用户注意到而智能体遗漏的点、最重要的失败、问题属于技能/提示/工具/工作流/判断哪一类、用户希望系统做出什么持久修复。
关注点：错误与失误（错误假设、工具误用、遗漏指令、事实或流程错误）；低效（耗 token 的探索、重复工作、不必要重试、可避免的浏览搜索、本可用简单工具或脚本之处）；死胡同（无帮助的调查、因上下文不清导致的循环、本应更早放弃的重复尝试）；有效之处（用户的有用框架、有效技能、强工作流步骤、快速路径、应保留的好启发式）。
根因分析：不停留在表面症状，对每个重要问题追问发生了什么、为何发生、什么使其得以发生、更深层模式是什么。根因常来自用户请求框架不清、技能指令缺失或薄弱、技能边界不当、缺少共享词汇、仓库/上下文可见性差、重复任务缺少轻量工具、工作流顺序不当、缺少检查点或评审门。
输出结构：Retro Summary（任务是什么、整体是否顺利、最大问题、最大优势）；What Went Wrong（具体失败、错误、延迟或死胡同）；Root Causes（问题背后的根因，区分症状与原因）；What Worked Well（值得保留的好模式及其有效原因）；Recommended Changes（具体改进，须实用且持久，而非“更小心”“做得更好”之类提醒）；Highest-Leverage Next Step（最先做的最有价值的一项具体改动）。
限制：绝不把复盘所得保存到 memory。唯一有效的产出物是技能（更新现有技能或创建新 SKILL.md）、文档（提交到仓库的 markdown，如 runbook、清单、参考文档）、脚本（提交到仓库的确定性辅助工具）。每条建议需说明改什么、为何有帮助、是高杠杆还是可选、应更新哪种产出物（技能、脚本或仓库文档）、以及确切的文件路径。结尾的下一步必须是对技能、脚本或仓库文档的具体改动，不能是模糊建议，也绝不能是 memory。若使用迭代模式，输出应体现询问用户后发生的变化。