retro-changes 是一个用于回顾单个已完成变更的 AI 技能。此处的“变更”可以是 GitHub 合并请求（PR）或 GitLab 合并请求（MR），状态包括已合并、合并后又修复或回滚、关闭未合并、本地分支，或本次会话中刚完成的工作。该技能旨在从变更的记录中找出“成本”——即消耗了某人时间且本可避免的事项，例如一轮评审、合并后的修复、用户的纠正——并进一步提炼出导致这些成本的根因“教训”。
主要能力：
- 定位变更及其状态：根据用户指定的 PR 编号/URL、分支或提交范围，或“本次会话”来确定目标，并判断其状态（已合并、合并后修复/回滚、关闭未合并、本地分支、本次会话）。
- 收集记录：读取 PR/MR 的描述、评审、内联评论、提交时间与评审时间的对比、失败的 CI 运行、关联工单评论、计划或规范等。对于已合并的变更，还会检查合并后基线上触及相同路径的提交，以发现回滚或修复。
- 识别成本：列出每个成本及其证据，例如导致提交的评审评论、第二轮或更晚的评审、修复失败 CI 的提交、合并后的修复或回滚、计划步骤错误、关闭未合并的原因，以及会话中的用户纠正、重做、被拒绝的工具调用等。
- 提炼教训：针对每个成本追问原因，直到找到代码、技能或缺失规则层面的可修复点。合并相同根因的成本，并丢弃一次性、无重复原因或已强制执行的项。
- 路由修复：将每个教训路由到最有效的修复方式，优先级为：代码（类型、规则、测试、CI 检查等）、用户自己的技能（仅当该技能导致了成本或未能捕获问题时）、文档或记忆（如 AGENTS.md、CLAUDE.md 或个人代理指令）。
- 报告并询问：以结论行开头，列出每个教训的成本、证据、责任方和修复方案，然后询问用户要应用哪些教训。
- 应用：仅应用用户选择的教训，在默认分支上编辑，运行仓库检查，并报告更改。
使用方式：该技能可在任何代理中使用。当需要询问用户时，优先使用代理的问题工具；否则以纯文本编号选项询问并等待回答。在只读或规划模式下，运行步骤 1 至 6，在对话中打印提案并停止。未经用户明确同意，不会写入、应用或发布任何内容，也永远不会在 PR 或工单上发表评论或提交。
适用场景：适用于开发团队或个人开发者回顾已完成的代码变更，从评审、CI、合并后修复等记录中提取可操作的改进点，并通过代码、技能或文档固化，以减少未来类似问题。
限制：该技能需要访问 GitHub 或 GitLab 的 API 以获取 PR/MR 数据，且依赖于变更记录的完整性。对于会话回顾，如果上下文被压缩，记录可能不完整，技能会说明记录不完整而非报告干净运行。该技能不会自动执行任何写操作，所有修复需用户明确同意。