一个人的技能，不如全团队共用
上一节写了个人技能。这一节的关键升级：把技能放进仓库，让全团队共享。这才是技能最大的价值——团队的最佳实践不再是「某个人脑子里的经验」，而是「仓库里的一份标准资产」。
对 codex-review 尤其如此：评审标准如果只在你个人目录里，那只有你审得规范，队友各审各的、标准不一。 把评审技能放进仓库，全团队跑 codex-review 都是同一套评审标准，这才是它作为「工作台」的意义。
为什么技能要共享
| 不共享 | 共享 |
|---|---|
| 每个人各自教 Claude | 一个技能，全组一致 |
| 新人来要重新摸索 | clone 下来就有标准 |
| 口头约定，容易走样 | 写在技能里，稳定可执行 |
本质：把「怎么干对」从人身上，固化到代码库。
对 codex-review，共享的收益是直接可见的：
- 标准一致：逻辑 / 安全 / 风格三路检查点、三档输出、冲突对账，全组同一个版本，评审结论可以横向对比。
- 新人快速上手：新人 clone 下来就有评审技能，不用先背评审规范，直接用同一套标准评审。
- 改进一处、处处生效：团队想给「安全」加一条检查点，改一处技能，全组的 codex-review 都升级。
怎么共享：放进 Git 仓库
做法很简单：把技能目录放进项目的 Git 仓库。
my-project/
.claude/
skills/
code-review/
SKILL.md
- 放进仓库 → clone 后全员自动可用
- 改技能 → 走 PR → 有变更记录，可回溯
- 命名规范、目录结构统一 → 好维护
对 codex-review，就是把它放进项目仓库的 .claude/skills/ 下：
my-project/
.claude/
skills/
codex-review/
SKILL.md # 我们的评审技能
放进仓库后，任何 clone 这个项目的人，立刻拥有同一个 codex-review 评审技能，无需额外安装、无需互相拷贝。
团队共享的三个原则
1. 统一规范
技能该有的内容、命名、输出格式，团队先定个标准。否则各写各的，很快变乱。
对 codex-review：团队要统一「评审技能放哪、SKILL.md 怎么写、输出必须含哪些字段（位置+问题+建议 / 三档 / 冲突对账）」。没有统一规范，技能库会失控。
2. 版本管理
技能变更走版本控制，别直接在共享仓库里乱改。谁改了、为什么改，要能查到。
对 codex-review：改评审标准是大事——比如新增一条安全检查点，等于全组的评审口径变了。这种变更必须走 PR、留记录、可回溯，否则评审结论会「昨天和今天标准不一样」。
3. 有负责人
每个核心技能有个 owner，负责维护和迭代。没人负责的技能，慢慢就腐烂了。
对 codex-review：评审技能要有明确 owner（通常是资深的 reviewer 或技术负责人），负责响应团队反馈、迭代检查点、确保它和项目规范同步。没人负责，评审技能会慢慢过时失效。
落地节奏
- 先挑 1-2 个「所有人都用得上」的技能起步（比如代码审查）
- 团队试用、反馈、迭代
- 稳定后再扩展更多技能
别一上来就搞一大堆，先让核心技能「好用、被用」，再滚动。
对 codex-review，落地节奏是：
- 先把评审技能放进仓库，让全组用起来（不用等它完美）
- 收集反馈：哪里审漏了、哪里误报了，记下来
- 迭代检查点：按反馈更新 SKILL.md，走 PR 合入
- 稳定后，再考虑扩展（比如加「性能评审」路）
常见误区
- 写得太复杂：技能太啰嗦，反而没人调用，保持精简
- 没人维护：技能放着不管，跟不上实践，慢慢失效
- 一人独用：写了个好技能却塞在个人目录，没分享——好的技能要共享
对应到 codex-review 的三个误区：
- 评审技能写太啰嗦：检查点堆了几十条，AI 执行累、人也懒得触发。保持每个子 Agent 的检查点精炼。
- 评审技能没人维护：项目规范变了，评审技能还停留在旧版，审出的结论过时。要有 owner 定期跟进。
- 评审技能一人独用：只有你个人目录里有，队友各审各的——最可惜。放进仓库，全组共享。
落地练习
codex-review/SKILL.md 移到项目仓库的 .claude/skills/ 下（如果还没放进去）；第 2 步，写一份「变更记录」，把这个技能的 owner、初始版本、评审范围（逻辑/安全/风格三路）写清楚；第 3 步，模拟一次「团队改进」——把安全路新增一条检查点，走一遍「改 SKILL.md → 说明改动原因 → 记录版本」的流程。② 怎么判断做对了：技能文件在仓库里且路径统一；owner 和版本有明确记录；你改动检查点后能说清「改了什么、为什么改、影响哪些评审」；clone 一个新副本能直接看到并使用这个技能。
③ 卡住了怎么办：如果技能路径不对导致无法触发，对照你所用版本文档的「技能目录约定」调整；如果担心改动影响全组，先在分支上改、说明理由，再合入主分支。
常见坑：评审技能「偷偷改了」，全组标准漂移
共享技能最大的隐患，是有人直接在共享目录里改了 SKILL.md 却没留记录。codex-review 里，这意味着全组无声无息地换了评审标准——昨天审出「必须改」的某类问题，今天标准改了不审了，可谁也不知道为什么。
对策：评审技能的每一次改动都走版本管理。新增/删除一条检查点、改输出格式，都要走 PR、写清「改了什么、为什么改、影响哪些评审」。评审是团队的共同标准，它的变更必须可追溯、可讨论，而不是某个人悄悄改。
小结
- 技能放进 Git 仓库 → 全员 clone 即用
- 三个原则：统一规范、版本管理、有负责人
- 先做核心技能，好用再扩展
- 别让技能变复杂、变废弃、变私有
- codex-review 评审技能已进仓库，下一节学怎么调试优化它
下一节，学技能的调试与优化——让 codex-review 在真实使用中越跑越稳。