retro

1用户要求做一次 **retrospective**。你要针对 coding agent 的 **environment** 提出改进建议，以改善未来的运行结果。
2 
3## 步骤
4 
51. 调用 Skill 工具并指定 `writing-for-agents`，获取写作风格指南。
6 
72. 阅读用户指定 session 的 primary sources。这可能意味着在本机搜索 session logs。如果用户没有指定 session，默认使用当前 session。
8 
93. 在以下类别中寻找改进候选项。
10 
11- **Navigation**：agent 找到正确 files 有多容易？files 之间是否存在隐藏依赖？navigation pointer 能否让定位更容易？当 agent 花了很长时间才找到某段信息时使用。
12- **Automated checks**：是否有 automated checks 可以捕获 agent 犯的错误？例如 linting、typing、tests 或 filesystem linters？先阅读 repo 自己的检查命令（`package.json`/build-tool 中的 `lint`/`check` scripts 以及 CI workflow），这样，如果某个检查已经存在但没有接入流程或悄悄失效，真正的发现就是这个问题，而不是重新发明一套检查。若 repo 完全没有 **guardrail**（没有 pre-commit hook，也没有运行 lint/typecheck/test command 的 CI job），这本身就是一项发现：未纳入 lint 的 repo 是长期存在的改进缺口，而不是理所当然的默认状态。当 agent 犯了本来可以被 automated check 捕获的错误，或 repo 完全没有 guardrail 时使用。
13- **Coding standards**：是否应该给 **reviewer agent** 一条新规则来执行？是否应该删除或澄清现有规则？先对违规分类：**mechanical** 违规（固定的语法模式、被禁用的 API、import 形式、文件位置规则）必须交给 deterministic check 处理；根据 repo 使用的语言和现有 guardrail，选择成本最低的方式：在 repo 自己的 linter 中添加自定义规则、新增 pre-commit hook，或新增 CI job。默认优先构建检查，而不是编写规则。`CODING_STANDARDS.md` 只用于真正的 **judgement calls**（跨文件一致性、"matches the surrounding style"，以及任何 guardrail 都无法替代的判断）。当 reviewer agent 没有发现一个错误时使用。
14- **Global AGENTS.md**：是否有 steering instructions 应该移到 coding standards 或 automated checks？当 repo 或用户 global scope 中的 AGENTS.md 特别庞大时使用。
15- **Tool economy**：agent 是否进行了可以简化的昂贵 tool calls？是否有特别消耗 tokens 的自定义 tooling（CLI、MCP 等）？当 agent 进行昂贵 tool call 时使用。
16…