retro

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

步骤

1. 调用 Skill 工具并传入 writing-for-agents，获取写作风格指南。

2. 读取用户指定的会话的主源资料。这可能意味着在本机上的会话日志中检索。如果用户没有指定会话，则默认为当前这个。

3. 在以下类别中寻找可改进的候选：

• 导航：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 缺少某条关键信息时使用。

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

参考

实现 vs 评审

记住所有工作都会经过两个阶段：实现和评审。实现 agent 承受最大的上下文压力。他们负责探索、写代码和调试失败。

评审 agent 的上下文压力最小：它接收的是 diff，不需要探索。它通常既不需要写代码也不需要调试。

这意味着评审 agent 应该负责落实编码规范，而不是实现 agent。

文件

你可以访问仓库里的几个文件：

• CLAUDE.md / AGENTS.md：这些文件会被推送到任何在该仓库中工作的 agent 的上下文窗口里。它们应当被极其克制地使用，通常仅用于指向其他文件的导航指针。
• CODING_STANDARDS.md：这个文件在评审时被读取，而不是在实现时。当标准文件超过 1,000 行时，新增指向 docs 文件夹的导航指针。
• Docs：把文档当作引用文件使用，由其他文件指向。在写新文档之前先看看是否已有现成的。
• Skills：把 skills 当作文档使用（因为它们的 description 会进入 agent 的上下文窗口），或者当作用户调用命令使用。遵循 writing-for-agents 技能中的建议。