/retro
对一次 coding session 做 retrospective。
$ npx -y skills add vinvcn/mattpocock-skills-zh-cn --skill retro --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/retro
Context preview
The summary Claude sees to decide when to auto-load this skill.
对一次 coding session 做 retrospective。
SKILL.md
retro.SKILL.mdname: retro
description: "对一次 coding session 做 retrospective。"
disable-model-invocation: true
用户要求做一次 **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。
文件
你可以访问 repo 中的几个 files:
- `CLAUDE.md`/`AGENTS.md`:这些 files 会被推入在此 repo 工作的任何 agent 的 context window。应当极其节制地使用,通常只放指向其他 files 的 navigation pointers。
- `CODING_STANDARDS.md`:这个 file 在 review 时读取,而不是 implementation 时读取。如果 standards file 超过 1,000 行,应当在其中加入指向 docs folders 的 **navigation pointers**。
- Docs:把 docs 当作 reference files,由其他 files 通过 pointers 指向。写新 docs 前先查找已有 docs。
- Skills:用 skills 承载 docs(因为它们的 description 会进入 agent 的 context window),或用于 user-invoked commands。遵循 `writing-for-agents` skill 中的建议。
Read more
name: retro description: "对一次 coding session 做 retrospective。" disable-model-invocation: true
用户要求做一次 **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。
文件
你可以访问 repo 中的几个 files:
- `CLAUDE.md`/`AGENTS.md`:这些 files 会被推入在此 repo 工作的任何 agent 的 context window。应当极其节制地使用,通常只放指向其他 files 的 navigation pointers。
- `CODING_STANDARDS.md`:这个 file 在 review 时读取,而不是 implementation 时读取。如果 standards file 超过 1,000 行,应当在其中加入指向 docs folders 的 **navigation pointers**。
- Docs:把 docs 当作 reference files,由其他 files 通过 pointers 指向。写新 docs 前先查找已有 docs。
- Skills:用 skills 承载 docs(因为它们的 description 会进入 agent 的 context window),或用于 user-invoked commands。遵循 `writing-for-agents` skill 中的建议。
Repo: vinvcn/mattpocock-skills-zh-cn
Other skills on vinvcn-mattpocock-skills.
code-review
从固定点(commit、branch、tag 或 merge-base)开始,按 Standards(代码是否符合本仓库记录的编码标准?)和 Spec(代码是否符合来源…
codebase-design
用于设计深模块的共享词汇。适用于用户想设计或改进模块接口、寻找深化机会、决定 seam 放在哪里、让代码更容易测试或更适合 AI 导航,或其他技能需要深模块词汇时。
diagnosing-bugs
面向棘手缺陷和性能回退的诊断循环。适用于用户说 “diagnose” / “debug this”,或报告某些东西 broken、throwing、failing、slow 时。

