Retro

---
name: retro
description: "对一次编码会话做回顾。"
disable-model-invocation: true
---

用户请求了**回顾**。你正在为编码 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` 技能中的建议。