# Retro

对一次 coding session 做 retrospective。

- Repository: https://github.com/vinvcn/mattpocock-skills-zh-CN (5461 stars)
- Category: Engineering
- License: MIT
- Last updated: 2026-10-28
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add vinvcn/mattpocock-skills-zh-CN --skill retro -g -a claude-code -y`
Codex: `npx skills add vinvcn/mattpocock-skills-zh-CN --skill retro -g -a codex -y`
Cursor: `npx skills add vinvcn/mattpocock-skills-zh-CN --skill retro -g -a cursor -y`
Gemini CLI: `npx skills add vinvcn/mattpocock-skills-zh-CN --skill retro -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add vinvcn/mattpocock-skills-zh-CN`

## Description

对一次 coding session 做 retrospective。

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

用户要求做一次 **retrospective**。你要针对 coding agent 的 **environment** 提出改进建议，以改善未来的运行结果。

## 步骤

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

2. 阅读用户指定 session 的 primary sources。这可能意味着在本机搜索 session logs。如果用户没有指定 session，默认使用当前 session。

3. 在以下类别中寻找改进候选项。

- **Navigation**：agent 找到正确 files 有多容易？files 之间是否存在隐藏依赖？navigation pointer 能否让定位更容易？当 agent 花了很长时间才找到某段信息时使用。
- **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 时使用。
- **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 没有发现一个错误时使用。
- **Global AGENTS.md**：是否有 steering instructions 应该移到 coding standards 或 automated checks？当 repo 或用户 global scope 中的 AGENTS.md 特别庞大时使用。
- **Tool economy**：agent 是否进行了可以简化的昂贵 tool calls？是否有特别消耗 tokens 的自定义 tooling（CLI、MCP 等）？当 agent 进行昂贵 tool call 时使用。
- **No-ops**：steering files 中是否有不改变 agent 行为的 instructions？当 steering files 庞大且难以维护时使用。
- **Information access**：是否有机会让 agent 获得更多信息？例如把 dev server logs tee 出来，或提供对 third-party services 的 read-only access。当关键的信息对 agent 不可用时使用。

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

## 参考

### Implementation 与 Review

记住，所有工作都经过两个阶段：implementation 和 review。implementation agent 承受最大的 **context pressure**，负责探索、编写代码和调试失败。

review agent 承受最小的 context pressure：它收到的是 diff，因此不需要探索。它通常也不需要编写代码或调试。

因此，review agent 应负责施加 coding standards，而不是 implementation agent。

The rest: https://github.com/vinvcn/mattpocock-skills-zh-CN/blob/HEAD/skills/engineering/retro/SKILL.md