讲解一下 Matt Pocock 最新 Skill：retro

回复 群友 484： 先说清定位：retro 是 Matt Pocock 的 mattpocock/skills 仓库里一个新加的 Skill，目前还放在 in-progress 目录（skills/in-progress/retro/SKILL.md），Matt 9 月 10 日在 X 上放话说"coming soon"，所以还没进 README 的正式清单，属于实验阶段。它的作用一句话讲：让 agent 对自己的上一次干活做复盘，但复盘的产物不是"下次注意点"这种空话，而是对你 agent 环境的具体修改建议。 这是它和普通"总结一下刚才做了什么"最大的区别。普通复盘输出的是文字感悟，retro 输出的是"你的环境该改哪一处"。它把改进候选分成七类，每类都绑了一个触发条件： Navigation（导航）：agent 找文件花了很久，就考虑加一个导航指针，或者在隐藏依赖之间补链接。 Automated checks（自动化检查）：agent 犯了一个本可以被 lint、类型检查、测试拦下的错，那就补检查。 Coding standards（编码规范）：reviewer agent 没抓到的错，给它加一条规则，或者删掉/澄清一条旧规则。 Global AGENTS.md：AGENTS.md 太大了，里面有些指令其实应该下沉成编码规范或自动化检查。 Tool economy（工具经济性）：agent 打了一次很贵的工具调用，看看这个 CLI 或 MCP 是不是 token 效率太低，能不能精简。 No-ops：steering 文件里那些根本不会改变 agent 行为的僵尸指令，找出来清掉。 Information access（信息获取）：agent 缺了某条关键信息——比如 dev server 日志没接进来、某个第三方服务只给了读写权限——那就给它补上读的通道。 举例说明这七类怎么落地。假设你让 agent 修个 bug，它花了 20 轮才定位到问题：如果这 20 轮是"到处 grep 找不到文件"，那属于 Navigation，建议是在 CLAUDE.md 里加一行指向那个文件；如果它明明写错了类型却没报错，那是 Automated checks，建议是打开 tsc 的严格模式；如果它反复跑一个全量 build，那是 Tool economy，建议是给它一个只编译单模块的脚本。同一场 session，不同症状对应不同类别的修法。 执行流程是四步：先调 writing-for-agents 这个 Skill 拿写作风格指南（因为产出物是写给 agent 看的文档，不是写给人看的），然后去读你指定那次 session 的原始记录（不指定就默认当前 session），再按上面七个类目挖候选，最后按严重程度排序呈现给你。 它内部还有一条挺值得单独拎出来的判断：实现和 review 是两个阶段，实现 agent 的上下文压力最大（要探索、写代码、调 bug），review agent 压力最小（只拿到一个 diff，不用探索也不用调试）。所以编码规范应该压在 review agent 身上，而不是塞给实现 agent——这也是它为什么把"给 reviewer 加规则"单列成一类。 另外它顺带给了文件职责的划分参考：CLAUDE.md / AGENTS.md 是会被推进每个 agent 上下文窗口的，要极其克制，通常只放导航指针；CODING_STANDARDS.md 只在 review 阶段读，不占实现阶段上下文，超过一千行就往 docs 目录拆；docs 用它当参考资料库，先看有没有现成的再写新的；Skill 则用来放"description 会进上下文"的东西或用户触发的命令。 想装的话，整个仓库是一把装的：Claude Code 里 claude plugins install mattpocock-skills，其他 agent 用 npx skills@latest add mattpocock/skills，装的时候可以自己勾选要哪些（记得把 setup-matt-pocock-skills 勾上）。因为 retro 还在 in-progress，能不能被单独选到，取决于安装器当时的清单，装上后如果没看到，直接去仓库拿那个 SKILL.md 手动放到你的 skills 目录也行。