用户请求了回顾。你正在为编码 agent 的环境提出改进建议，以提升后续运行的体验。

步骤

调用 Skill 工具并传入 writing-for-agents，获取写作风格指南。
读取用户指定的会话的主源资料。这可能意味着在本机上的会话日志中检索。如果用户没有指定会话，则默认为当前这个。
在以下类别中寻找可改进的候选：

导航：agent 找到正确文件的难易程度如何？文件之间是否存在隐藏依赖？一个导航指针会让事情更简单吗？当会话花很长时间才找到某条信息时使用。
自动化检查：是否存在能捕捉 agent 所犯错误的自动化检查？linting、类型检查、测试、文件系统 linter？先读仓库自己的检查命令（它的 package.json/构建工具的 lint/check 脚本、它的 CI workflow），这样发现就落在"已经存在、但没接线或悄悄坏掉"的检查上，而不是重新发明一个。没有任何护栏（没有 pre-commit hook，也没有跑 lint/typecheck/test 的 CI job）的仓库本身就是一条发现：未 lint 的仓库是一个长期错失的机会，而不是中性的默认状态。当 agent 犯了一个本可被自动化检查捕获的错误，或仓库完全没有护栏时使用。
编码规范：是否应给评审 agent 一条新规则去执行？是否应删除或澄清已有规则？先给违规分类：机械性违规（固定的语法模式、被禁用的 API、某种 import 形态、文件位置规则）一律走确定性检查：在仓库自己的 linter 里加自定义规则、加一个新的 pre-commit hook、或加一个新的 CI job，哪个在仓库的语言和现有护栏下最便宜就用哪个。默认优先构建检查，而不是写规则。把 CODING_STANDARDS.md 留给真正的判断题（跨文件一致性、"与周围风格一致"、任何护栏永远无法替代的东西）。当评审 agent 没抓住错误时使用。
全局 AGENTS.md：是否有些引导指令应当改为编码规范（或自动化检查）？当 AGENTS.md 文件特别庞大时：无论是在仓库还是用户的全局作用域：使用。
工具经济性：agent 是否做了昂贵且可以精简的工具调用？是否存在特别消耗 token 的自定义工具（CLI、MCP）？当 agent 做了昂贵的工具调用时使用。
空操作（No-ops）：在引导文件里寻找那些并不修改 agent 行为的指令。当引导文件庞大且难以驾驭时使用。
信息访问：寻找可以提升 agent 信息访问能力的机会。Tee 出开发服务器的日志、对第三方服务的只读访问等。当 agent 缺少某条关键信息时使用。

按严重程度顺序向用户呈现这些候选。

retro

步骤