Claude Code 项目级 Skill：团队协作场景下的使用场景

今天这篇我们来聊下 claude code 的skills机制吧。

其实我在带着团队一起项目开发协作的时候经常会反思或者疑惑，在我们几个一起搞这个项目的时候，真的需要搞项目级 skill吗？这样到底算不算过度设计，反而增加了复杂度？

其实整个体验下来，带给我的实际体验是这样的：

[!info] 大多数时候是不太需要这个项目级 skill 的

我个人的感觉，在这些情况下就尽量不要过度设计，去折腾了：

[!example]

团队就 2-3 个人，大家其实可以开个会，有啥问题直接说的

项目很简单，也没有什么特殊的评审流程、部署流程等这些

团队成员都很熟悉项目规范了，也不需要反复提醒

大家用 ai 的方式都差不多，也没有什么标准不统一的问题

我觉得在这种情况下，搞项目级 skill 确实是为了用而用，纯粹增加复杂度。

但是我日常项目中还是会用到项目级别的 skill，比如我有的项目总是会遇到这些问题：

[!example]

某些操作步骤虽然固定但很繁琐，每次都要重新跟 ai 解释一遍

团队是有公司特定的评审标准的，特别是一些大厂，但是经常有人忘记或做错

不同人用 ai 写出来的代码风格差异很大，code review 很痛苦,就比如我每次发版都是痛苦。

团队经常有新人加入，每次都要重新教一遍规范，随着大环境的不好，比如我们公司项目组经常会来回调动不同的同事或者外包参与。

那这种情况下，其实项目级 skill 就不算是太过度设计，而是真的能解决一些问题。

特别是针对于 ai 提效，ai 团队使用分享，ai 工具进阶使用这种不管是面试需要还是学习的角度来说，还是需要多了解学习一下的。

前面我已经写了 claude code 的 hook 机制还有 rules 机制，所以这篇呢我再讲讲 skill 机制。

所以这篇呢 其实还是以我的角度和经验来写一篇分享文，我说的这些机制并不是需要我们在项目中都要求用到，而是我们需要先了解这些机制，这样我们在团队协作中遇到问题才知道我们可以使用哪些机制来约束我们团队 ai 开发中遇到的各种问题。

[!info] 尽量不要为了用而用，从而复杂化我们的团队项目开发流程哈。

这篇呢我其实主要讲这个方面，一个就是我们什么时候需要用到 skill？ 以及我们什么时候需要全局skill 什么时候需要用项目级skill。

---

一、什么是 skill(大概理解下就行)

虽然很多同学其实都比较了解了，但是这里我们还是简单理解一下哈，先说官方定义：

[!info] skill 是可复用的指令集，用于扩展 claude 在特定任务上的能力。

这句话听起来感觉有点抽象，那我们换个说法来理解的话，其实 skill 就是把一个复杂的、多步骤的任务流程，写成一个可以一键触发的指令集。

比如说，我们日常开发中需要做代码评审，所以可能就要做这些流程：

[!example]

• 需要先跑 git diff 看看代码都改了哪些文件内容


• 再检查下看看是否有代码逻辑错误的


• 然后再看看有没有安全风险以及需求边界的问题


• 最后输出一份代码开发逻辑说明报告

如果我们每次执行这些流程的时候都要跟 ai 重新说一遍这个流程内容，那也太麻烦了都。

但如果我们把这个流程写成一个skill的话，然后把目录命名为.claude/skills/review/，那我们以后只要输入/review，ai 就知道按这个完整流程走逻辑了。

所以 skill 不是检查，而是执行任务的完整流程。

这里我再举几个类似的例子：

[!example]

• /commit：整理 git diff,然后生成 commit message，最后建议是否拆分提交


• /deploy-check：类型检查,跑测试,跑 lint,然后构建，输出是否可以部署

---

那skill 是怎么被触发的呢

使用过 skill 的同学应该知道，skill 一般有两种触发方式：

[!example]

• 手动触发：我们直接输入 /skill-name，比如 /review


• 自动触发：claude 根据我们说的话，自动匹配到某个 skill 的 description，然后触发

但是这里有个很重要的机制我们还是要理解一下。

claude code启动的时候，并不会把所有 skill 的内容都加载进来的，那样太占上下文了。

默认情况下，它主要加载每个 skill 的名称和 description，让 Claude 知道当前有哪些skill 可以用，以及什么时候应该自动触发。

当 skill 被触发时，不管是用户手动输入 /skill-name，还是 Claude 根据 description 自动匹配到这个 skill，Claude Code 才会读取这个 skill 的完整内容（SKILL.md）。

不过这里有一个例外：如果某个 skill 在 frontmatter 里配置了 disable-model-invocation: true，那它就不会进入 Claude 的自动触发列表。也就是说，Claude 不会根据对话内容主动调用它，只有用户手动输入 /skill-name 时才会加载完整内容。

所以 description 很重要，但也不是所有 skill 都需要写成“方便自动触发”。像部署、提交发版、数据库迁移这类有副作用的流程，反而建议加上 disable-model-invocation: true，只允许用户手动触发。

具体 description 怎么写，我们后面在怎么创建项目级 skill 那里再详细说一下吧。

---

skill 和其他机制的区别

我在之前的文章分享里面或者别人的帖子里面会遇到有的人不太理解skill 和 CLAUDE.md、rules、hooks 这些机制的区别。

这里我先简单总结一下，然后具体怎么配合我们放在后面去讲。

总结的来说是这样的：

[!example]

• CLAUDE.md：项目事实说明规范，目的是告诉 ai 这是什么项目 以及全局约束


• rules/：编码规范约束，目的是为了告诉 ai 代码怎么写


• hooks：底线强制拦截，目的是为了告诉 ai 不能做什么


• skills/：任务执行流程，目的是为了告诉 ai 特定任务怎么做

明白了这些，我们在团队协作中需要用到这些机制来辅助 ai 开发的时候，就知道什么情况下需要用到哪些机制了。

---

二、为什么团队协作需要项目级 skill

在讲为什么之前，我们照常还是先理解一下 skill 的存放位置吧。

这点其实我们都很清楚了，skill 是可以放在不同的位置的，放在哪里就决定了谁能用到它。

skill 可以放在哪些地方

个人全局 skill

这个是我们最常用的，一般放在 ~/.claude/skills/ 下面，这是我们个人的全局 skill。

装在这里的 skill，我们自己所有项目都能用到，但别人用不到。一般我们从 skill 市场安装的，或者我们自己写的个人 skill，都是放这里。

项目级 skill

顾名思义，就是放在项目的 .claude/skills/ 下面的，这是项目级别的 skill。

装在这里的 skill，只有这个项目能用，而且提交到 git 后，团队所有人 clone 下来就都能用到。

企业级 skill

这个我用的不多，也了解的不多，这里我们只做了解哈，这个是企业统一管理的 skill，组织内所有人都能用，不过这个得看公司有没有配置。

插件 skill

插件自带的 skill，装了插件就能用的。。。

简单来说哈，我们日常用得最多的其实就是这两种：

[!example]

• 个人全局 skill：~/.claude/skills/，自己用


• 项目级 skill：.claude/skills/，团队共享

明白了这些去吧，那我们接着往下看。

---

个人开发用全局 skill 其实就足够了

其实很多同学都会用到 skill 在项目中进行开发，如果是我们个人项目开发的话，全局 skill 已经很满足我们的日常开发需求了。

我们从 skill 市场装几个常用的 skill，比如 /superpowers，/grill-me等等这些，放在 ~/.claude/skills/ 下面，所有项目都能用，是挺方便的。

但是如果用到团队开发中的话，其实也没问题，但是却还不够。

在我们团队项目开发协作过程中，如果仅仅只用全局 skill 其实还是不够的，毕竟每个项目都不太一样，每个人使用的 skill 也不一定都相同，使用方式也都不一样的。

团队协作中会遇到的问题

还是举个日常例子哈，比如我们团队有个安全评审流程，要求必须检查这些：

[!example]

• 公司特定的密钥命名规范，比如必须是 KEY_* 或 SECRET_* 开头


• 数据库操作是否走了公司的审计层，必须通过 src/lib/services/


• 权限系统的越权访问，我们有特定的权限系统的


• 输出报告必须按公司模板，CRITICAL / WARNING / INFO 三级

日常开发过程中，每次到了做安全评审的时候，我们都要跟 ai 重新解释一遍这些要求。

有时候忘了说某一条，ai 就按通用逻辑来，结果漏掉了公司特定的风险点。

或许更麻烦的是，团队其他同事可能也慧遇到同样的问题，比如同事a不知道要检查数据库审计这些，ai也不知道，同事 b不知道公司的权限系统，ai就会按通用逻辑判断，结果漏报了越权风险。

虽然大家都装了一些通用的skill，但那是通用的代码评审流程，并不包含我们公司特定的安全要求。

说到这里可能会有人想到一个点，那就是这些要求为啥不写到 CLAUDE.md 或 rules 里面去呢？

比如公司特定的密钥命名规范，必须是 KEY_* 或 SECRET_* 开头，这不是全局规范吗？ 写到rules 里不就行了？

其实我觉得这就是很多人容易搞混的地方。

我们确实可以在 CLAUDE.md 和 rules 里面去要求 ai 去执行这些规范，但问题是，我们面对的不是一个点的检查流程。

CLAUDE.md 和 rules 只是为了让 ai 开发的时候尽可能按照我们的建议去规范，但是当我们需要执行一个完整的安全评审流程时，它们就没有办法了。

我举个例子，比如我们可以在 rules 里写密钥必须是 KEY_* 或 SECRET_* 开头,数据库操作必须走 src/lib/services/ 审计层这些说明。

但是rules 是 ai 写代码时要遵守的规范，不是评审代码时要执行的完整流程。这就是为什么我们需要 skill，因为 skill 是用来执行完整的工作流程的。

---

全局 skill 解决不了哪些问题呢

ok，也许还有的同学可能会觉得那我们自己写个全局 skill 不就可以了吗？

其实还是不行的，因为全局 skill 在团队协作中有这些问题，比如：

全局 skill 是跨项目通用的，不是团队特定的

假如我们有多个项目，而且每个项目安全要求还不一样，比如 A 项目是对外 api， 需要要检查 xss 和 csrf 这些，而B 项目是内部管理系统，重点是权限控制，C 项目涉及支付，要检查 pci dss 合规等等。

如果我们把所有项目的安全要求都写到全局 skill 里，那这样的话skill 就会变得又长又乱，而且ai 不知道当前项目该用哪套规则，其他项目用不到的检查项也会触发。

团队成员的 skill 版本不一致

一般情况下，安全评审流程是会更新的，比如上个月公司新增了一个审计层要求，那我更新了自己的全局 skill，但其他同事却不知道要更新，结果大家的评审标准就不一样了。

新人不知道要装哪些 skill

这里我们还说下团队加入新成员的问题，同样的，有新人加入团队，就不知道公司有特定的安全评审 skill，装的都是通用 skill，评审时漏掉公司特定的检查项，等到 code review 时才发现问题就晚了。

所以单靠全局 skill，不能更好的解决团队协作的问题。

---

所以说项目级 skill 能解决什么呢

上面我们提到过，项目级 skill 就是仅在此项目中使用的 skill，是放在项目的 .claude/skills/ 目录下的。

我们可以把团队的安全评审流程写成项目级 skill，放在 .claude/skills/security-review/SKILL.md，提交到 git。

这样的话新人 clone 代码就能用，流程更新后 git pull 就能同步，所有人用的都是同一套标准。

所以简单总结来说，项目级 skill 其实有这几个很好的使用价值：

1. 工作流标准化 团队协作可以统一执行流程，不再是每个人各自理解。


2. 隐性知识显性化 大佬的经验可以沉淀下来，新人也能按标准流程执行。


3. 新人 onboarding 自动化 git clone 代码就能用，也不用额外配置，不用看一堆文档了。

---

三、两个案例：我自己项目和公司项目的两个场景使用

前面讲了那么多理论了，那现在我们直接来看两个真实例子吧。

场景一：PR 评审 skill

我之前有提到过，我有一个叫 Auriga 的项目，是一个企业级的自动化发布平台，后端 Go，前端 Vue，团队一起在开发。

这个项目有个硬性要求：每次提 PR 之前，都要按照团队规范检查一堆东西，比如 Go 代码有没有跑 gofmt、Vue 组件命名对不对、有没有不小心把 .env 或者构建产物提交上去、数据库迁移脚本放对地方没有等等。

主要是我个人团队项目 没有测试，如果不去验证更新到测试服就会很麻烦，维护起来也麻烦，所以就做成每次提交的硬性指标要求，但是这些检查项每次都一样，但每次都要人肉过一遍，很容易漏。所以我就想，干脆写成一个项目级 skill 吧，以后直接 /pr-review 一键评审。

下面我就完整讲一下这个 skill 怎么写、怎么用。

先看看团队已有的规范

在写 skill 之前，我们需要先知道团队的规范是啥。

其实我这个项目里已经有一个 AGENTS.md 文件了，里面写了很详细的协作规范，比如：

这些规范其实就是我们评审 PR 时要检查的项。而skill 要做的，就是把这些检查项固化成一个流程。

完整的 SKILL.md

我们在项目的 .claude/skills/pr-review/SKILL.md 里写这个 skill，完整内容是这样的：

上面这个写的比较精简了，实际用的时候检查项可以写得更细的。

这里需要注意一个细节：/pr-review 这个命令名不是由 frontmatter 里的 name 字段决定的，而是由 skill 所在的目录名决定的。

也就是说，因为这个文件放在：

.claude/skills/pr-review/SKILL.md

所以它的调用命令才是 /pr-review。

其中 name字段更多是显示名称， 这里我不建议把它理解成命令名哈。比如如果我们的目录是.claude/skills/review/SKILL.md，即使里面写了name: pr-review，普通项目级 skill 的调用命令也仍然是/review哦。

这个 skill 的几个关键点

写完之后我们回过头来看下这个 skill 有几个点是团队协作时比较关键点的：

description 写得很具体

我没有写帮助评审代码这种模糊的概念，而是明确列出了检查什么比如代码规范、测试覆盖、提交信息、安全风险等，还有什么时候触发特别是当用户要求做 PR 评审、代码评审、检查变更时。

这样团队成员给 ai说帮我评审下这个 pr 或者检查下我的变更，ai 都能触发了。

用 allowed-tools 预先授权

因为这个 skill 要跑 git diff、git log、gofmt 这些命令，所以我在allowed-tools 里预先授权了。

不过这里要注意，项目级 skill 里的allowed-tools并不是无条件生效的哦。官方文档里也提到了，提交到项目.claude/skills/ 里的 skill，如果配置了allowed-tools，就需要用户先接受当前仓库的 workspace trust 之后才会生效的。

也就是说，团队成员第一次在这个项目里使用这些 skill 时，仍然应该先确认下这个仓库是可信的。确认之后，skill 处于活动状态时， claude 才可以免确认使用这些被预先授权的工具 哦 。

用了动态上下文注入

!`git diff HEAD` 这几行会自动执行，把当前的代码改动、文件清单、提交历史都注入进来。

这样 ai 一上来看到的就是真实的变更，不需要每个人手动去贴代码了。

检查项是项目特定的

比如"数据库变更要放在 resource/sql/"、“不要提交 public/ output/”，这些都是 Auriga 项目特定的规范。

通用的评审类 skill 其实根本不知道这些，所以我们必须写成项目级 skill才可以。

实际跑一下看看效果

配置好之后，我在项目里直接输入命令/pr-review，ai 就自动按流程评审了。

可以看到它输出了一份结构化的报告，大概长这样：

从图中可以看到，ai 自动拿到了我的变更内容，然后按照团队规范逐项检查，最后给出了明确的评审结论，还贴心地给了后续跟进建议。

这个报告格式是统一的，团队所有人用这个skill 评审出来的报告基本上都长一样的，看起来就很规整。

这个 pr-review 是典型的检查型 skill，是基于团队已有规范，把检查流程固化下来的。

---

复杂 skill 不要都塞进 SKILL.md

上面这个例子为了方便展示，我把检查项和输出格式都写在了SKILL.md里面。

但如果是我们团队项目长期维护的项目级 skill，我更建议拆成多个支持文件。

比如实际上 pr-review 可以这样组织：

我们这样来规划的话还是有这几个好处的，比如：

[!example]

• SKILL.md可以保持简洁，不会越写越长的


• 不同规范可以分文件维护，比如前端同学可以维护frontend.md，后端同学维护backend.md，是不是跟 rules 很相似。


• 报告模板可以单独去调整，不会影响评审流程的


• 如果有固定的数据收集逻辑，我们还可以放进scripts/，这样避免每次让 ai 临时拼命令

然后SKILL.md里只需要写清楚什么时候读取这些文件就好了。

这样 claude 不需要一开始就把所有细节都加载进上下文，而是在需要的时候读取对应文件。

官方文档里也提到，skill 目录里除了必需的SKILL.md，还可以放模板、示例、脚本、参考资料等支持文件的。所以对我们团队项目来说，这个能力很实用的，因为真正长期维护的skill 往往不是一个文件能讲清楚的。

---

场景二：数据库迁移 skill

这一个是我们公司的项目在版本开发时遇到的场景，关于 sql不管是新增字段、修改表结构还是创建新表，线上更新的时候都必须按照统一的打包规范来提交迁移脚本。

这个规范要求必须按照固定的5层目录结构来组织 的，而且每一层的命名都有明确要求。

比如我们项目里已经有sql/create/（放新建表）和sql/alter/（放修改表）两个目录，开发过程中sql 文件都放在这里。发版的时候，我们要把这次有 git 变更的sql文件按照规范打包成一个 zip。

这个过程靠人工来做特别容易出错，而且每次都要再去看一遍文档，因为这个只有版本更新的时候才需要，先要git diff看看哪些文件变了，再手动创建5层目录，复制文件， 而且还要保证命名符合规范。层级多、命名规则复杂，很容易搞错。

所以我就写了个/db-migration的skill，让它自动按规范生成。

比如我们公司的 sql 打包规范是这样的：

而且还有一堆限制：

[!todo]

• 比如zip 包命名必须是项目_版本_维护日期.zip这样的


• 如果有执行顺序的话，必须通过step1、step2 来区分


• 而且目录名不能包含中文


• sql文件名必须是{库名}.sql这种形式


• 如果是长事务必须加超时设置set innodb_lock_wait_timeout=3600这种命令

我们每次版本更新手工创建这些目录、命名，特别容易搞错。所以我们就可以创建一个项目级的 skill 来一键化操作。

比如我们在 .claude/skills/db-migration/SKILL.md 里写这个 skill：

[!tip]

这里我特意加了 disable-model-invocation: true。因为数据库迁移打包不是一个纯检查动作，它会创建目录、复制文件、生成发版交付物，属于有副作用的流程。

这类 skill 我个人不建议让 claude 根据上下文自动触发，而应该由用户明确输入 /db-migration后再执行。否则有可能我们只是聊到“发版 SQL”或者“数据库迁移规范”，claude 就误以为应启动打包流程。

所以一般来说，像部署、提交、发版、数据库迁移、发送通知这类会改变文件或影响外部系统的skill，都建议设置成只允许手动触发。

我们来看下这个 skill：

自动检测 git 变更

skill 会自动跑 git diff --name-only HEAD origin/master – sql/，找出哪些 SQL 文件有变更，不需要人工去看。

description 明确了使用场景

因为这个 skill 设置了 disable-model-invocation: true，所以它不会被 claude 自动触发。团队成员需要明确输入 /db-migration 来启动这个流程。

allowed-tools 预先授权了必要命令

因为要检测 git 变更、创建目录、复制文件，所以授权了 git diff、mkdir、cp 这些命令。

把复杂规范固化成自动化流程

5 层目录、每层的命名规则、SQL 文件的复制和重命名，这些全部自动化，不会出错。

这是项目特定的打包规范

别的项目根本不会用这套目录结构，通用的数据库工具 skill 也不知道我们项目 sql/create/ 和 sql/alter/ 这个约定，必须写成项目级别的 skill。

这样所有的检测、创建、复制、命名都是自动按规范来的，我只需要提供打包信息就行。

---

怎么提交和团队共享

写好这个 skill 之后，怎么让团队其他人也能用呢？

其实很简单，因为它就在项目的.claude/skills/目录下面，我们就可以直接提交到 git 就行的。

然后团队其他同学只要去拉一下代码，重启 claude code或者新开个会话，就能看到我们写的/pr-review这个命令了。

如果这个skill只是纯说明类流程，基本不需要额外配置的。但如果它配置了allowed-tools，团队成员第一次使用时还需要确认当前仓库的 workspace trust哈。这个确认很重要，因为allowed-tools本质上是在 skill 激活时给 claude 预先放行一部分工具权限 的。

怎么维护和更新

这里就很好理解了，比如过了段时间，我们的团队规范可能会变。比如新增了一条要求是所有对外接口必须加限流。

那我们只要改一下SKILL.md文件，在评审步骤里加一条对应的检查项，然后更新到仓库，这样团队成员更新之后，新的检查项就自动生效了。

这样所有人用的都是同一套最新标准，不会出现我更新了但别人还在用老版本的情况。

这个其实就是把项目级 skill 在团队协作中的完整用法串起来了：

[!example]

• 基于团队已有规范从 AGENTS.md 里提炼出检查项


• 然后写成完整流程比如description + 动态注入 + 检查步骤 + 报告格式


• 最后提交共享，放在.claude/skills/里面，提交 git，团队更新就可以用了


• 然后可以更新同步，当规范变了改skill，push 后所有人自动同步


• 而且对新成员友好，新同事拉代码就能用，不用再重新学一遍规范了。

我想这就是项目级 skill 最实在的价值吧：

[!info]把团队的隐性规范变成了可以一键执行的流程规范。

---

四、团队协作中的实际用法

上一节我们完整做了一个pr-review 的 skill，也知道怎么提交共享了。但其实真正用起来的话，还有几个点我觉得还是要再说下哈。

什么情况下适合写项目级的skill

我见过有的同事是这样的，学会了skill 之后就特别兴奋，然后一口气建了十几个 skill，什么评审的、部署的、生成文档的、写测试的，但是大部分 写的 skill都去吃灰了，可能比较想多产出吧，但是基本上就没怎么用了都。

主要还是很多 skill 其实并不是团队真正的痛点，只是看起来有用而已。

我的建议是，先观察一段时间，看看团队在协作中到底哪些事情是真的重复、真的比较麻烦的。比如我那个 pr-review，就是因为每次提 PR 前都要人肉检查一堆规范，实在太烦了，才写的。这种高频、重复、还容易漏的场景，才值得写成 skill

---

团队反馈收集和迭代

还有一点就是skill 并不是写完就完事了，尤其是团队一起用的时候。

因为我们自己写的时候觉得没问题，但别人用起来可能就有各种情况。比如有的同事说他是用的时候没有触发，那可能是 description 关键词不够，有时候会漏掉某些检查，那可能是评审步骤写得不够明确，还有的时候可能某个检查不需要了，那可能是规范变了，skill 该更新了

要知道这些反馈其实都很有价值的。我们可以根据这些反馈去调整 description 或者评审流程，让 skill 越来越好用。

所以团队 skill 是需要持续维护的，并不是一锤子买卖。用的人多了，反馈多了，它才会越来越贴合团队的实际需求。

---

和 hooks 的配合

其实不同的技能之间是可以搭配使用的，比如skill 和 hook 怎么配合，因为这俩其实经常一起用。

比如我上面例子中的那个 pr-review 里的 allowed-tools ，就这个

allowed-tools: Bash(git diff *) Bash(git log *) Bash(gofmt *) Read(*)

这个就是预先授权，让 skill 在执行时可以直接跑这些命令，不用每次都弹权限问我们。

但这里有个容易误解的地方：allowed-tools 只是预先批准这些工具，不代表 claude 在这个skill 里只能用这些工具。

也就是说，allowed-tools: Bash(git diff *) Read(*) 的含义是：当这个 skill 处于活动 状态时，Claude 使用这些工具不需要再单独确认。但其他工具并不会因此被禁用，只是仍然会按正常权限规则处理。

如果我们希望某个 skill 运行时明确不能使用某些工具，就要用 disallowed-tools。如果我们希望在整个项目里都禁止某类操作，就应该放到权限配置或 hooks 里处理。

而 hook是另一个层面的东西。比如我那个 Auriga 项目里就有个 hook，专门拦截对 .env、.key、.pem 这些敏感文件的修改。

那其实就可以搭配一下，比如 skill 的 allowed-tools 用来告诉 claude执行这个 skill时，哪些工具可以预先放行；而 hook 负责做全局兜底，不管什么 skill 被触发，只要碰到敏感文件就一律拦截。

简单来说 一个做的是在有限规则内尽量放行，但是另外一个就是在放心的范围内做到规则内检查拦截.

和 rules 的配合使用

其实这个我也说过，rules 和 CLAUDE.md的性质类型差不多，都是为了让 ai 写代码时要遵守哪些规范。但是只是建议，并不代表会强制执行。

所以我们就可以在适当的规则内创建一个 skill 进行检查校验，去检查这些规范有没有被遵守。 一个是写的时候管着，一个是审的时候查着，两个互相制约配合。

我之前写 rules 的时候有的佬分享可以吧 rules 直接改成 skill 来使用，不过我的建议还是别把 rules 里的规范一股脑全塞到 skill 里了，也别指望 skill 能替代 rules。因为它俩是配合关系，不是替代关系。

[!info] rules 是持续生效的编码约束，skill 是按需触发的任务流程，定位完全不同哈。

---

五、四层机制的完整体系

讲个疑问，claude code 里面机制这么多，那CLAUDE.md、rules、hooks、skills，我们到底什么时候该用哪个呀。

这里我就把这几个机制还是简单再梳理下，给个完整的对比和决策方法。

四层机制对比

我们先简单总结下这四层机制的定位：

用一个场景串起来

比如我们在CLAUDE.md 里写了项目事实：

然后rules/security.md 里写了安全规范：

hooks 里配了强制拦截：

这个 hook 会拦截对.env、.key、.pem 等敏感文件的修改操作的。

然后skills/pr-review 里写了完整的评审流程：

[!todo]

• 检查代码是否符合规范（rules 里的内容）


• 检查有没有误提交敏感文件


• 检查数据库变更是否放对位置


• 输出结构化的评审报告

这样组合之后，团队协作里的分工就比较清楚了：

[!todo]

• 写代码时，claude 通过 CLAUDE.md 理解项目结构和基本约束，通过 rules/ 理解编码规范。


• 如果 claude 试图修改 .env、.key、.pem 这类敏感文件，PreToolUse hook 会直接拦截。


• 提 PR 前，团队成员再手动触发 /pr-review，按项目级 skill 固化的流程做一次结构化检查。

决策树：遇到需求该用哪个

我画个简单的决策流程：

这里我们把其他机制也简单提一下吧

其实 claude code 还有其他一些机制，比如：

但对大多数团队来说，我觉得CLAUDE.md + rules + hooks + skills 这四层已经够用了。

等团队真正用熟了，有更复杂的需求时，我们再去研究那些高级特性也不迟的。

---

依旧最后总结下

写到这里，关于项目级 skill 在团队协作中的用法我个人的体验就差不多到这里了。

其实从团队协作角度来看，我觉得项目级 skill 的价值其实就三点吧

[!example]

工作流标准化，所有人都用同一套流程，不再各自理解了

隐性知识显性化，老同事的经验沉淀下来后，新人也能按标准执行了

新人onboarding 自动化，直接拉代码就能用，不用看文档学规范了

当然，这套机制不是说每个项目都必须全上哈。如果是小团队、小项目的话，可能一个 CLAUDE.md 就足够了，但一旦团队规模变大了，协作流程变的复杂，或者新人、外包、跨组协作变多，这些机制的价值就会慢慢体现出来了。

不过后面我应该不会继续只围绕 claude code 的机制来写了。

因为我们团队现在也开始把 codex 作为团队里的 agent 工具来使用了。而且它跟我们用的 calude code 的协作方式、上下文管理、项目规范沉等还不太一样，后面我整理整理看看能不能也分享一起学习讨论下哈。

官方文档学习参考：使用 skills 扩展 Claude - Claude Code Docs