当开发者想要团队 skill 的变体——额外检查、不同输出格式、领域专属补充——他们在 ~/.claude/skills/ 创建个人 skill。它是用户范围的、不版本控制的、只有那个开发者在所有项目中可用。
唯一不能违反的规则：起个和项目 skill 不同的名字。
个人 skills 怎么工作
| 位置 | 范围 | 版本控制 | 团队可见 |
|---|---|---|---|
.claude/skills/review/ | 项目 | 是 | 是 |
~/.claude/skills/my-review/ | 用户 | 否 | 否 |
想要安全聚焦版 /review 的开发者创建 ~/.claude/skills/security-review/SKILL.md。他们调用 /security-review 用增强版，团队继续用 /review 不变。
创建过程很直接：复制共享 skill 的 SKILL.md，重命名目录，加你的定制。从共享 skill 出发确保个人变体包含团队已验证的基础功能。
遮蔽问题
如果开发者把个人 skill 命名为 deploy-check——和项目的 /deploy-check 完全一样——个人版本在那个开发者的机器上遮蔽了团队 skill。他们调用 /deploy-check 时，得到的是个人变体，不是团队的。
一个团队发现这个问题是因为某个开发者的 CI 运行开始缺少安全验证。那个开发者创建了一个没有安全步骤的个人 deploy-check skill。在他机器上，每次 /deploy-check 调用都跑的是他的个人版本。其他团队成员看到不同结果因为他们跑的是项目 skill。
这不是 bug。Claude Code 不会自动给个人 skill 加用户名前缀做命名空间。名字冲突时，个人版本在那个开发者的机器上优先。
命名约定
修复很简单：用不同的名字。两种常见模式：
- 描述性前缀：
my-review、my-deploy-check - 首字母前缀：
jd-review、km-extract
一个 6 人团队跟踪了一个月的采用情况。三个开发者创建了个人 skill 变体。全部用了首字母前缀的名字。共享 skill 使用量保持不变，约 20 次调用/天。零遮蔽事件。
前缀约定轻量且有效。不需要注册表、审批流程或集中执行。
什么不该放在用户范围
个人 skills 是给个人偏好的——格式风格、额外的领域专属检查、输出格式变体。它们补充共享 skills，不替代它们。
不该是个人 skill 的东西：
- 全团队依赖的关键工作流（放
.claude/skills/） - 必须对所有人生效的标准（放 CLAUDE.md）
- 必须产出一致结果的 CI/CD 工作流（放
.claude/skills/）
把 /deploy-check 放在 ~/.claude/commands/ 然后期望全团队都有的开发者创造了”我机器上能用”问题。团队关键工作流必须在项目范围。
什么不该放在项目范围
反过来也成立。一个高级开发者提议：“所有 skills 都该在项目仓库里以便可见。个人 skills 创造了隐藏配置。”
这会用 10 个开发者的个人格式偏好塞满共享项目配置。个人 skills 不影响其他开发者——它们只改变开发者自己机器上的行为。调试的顾虑有道理（如果一个开发者的输出不同，团队可能需要问他的配置），但通过沟通解决比消除个人定制更好。
扩展，不是替代
个人 skills 补充团队工作流。引入个人 skills 后，一个团队测量到：
- 共享 skill 使用量：不变
- 个人 skill 采用：6 个开发者中 3 个
- 命名冲突：零
个人 skills 补充了共享的。开发者两个都用——共享 skills 做标准团队工作流，个人 skills 做定制需求。
一句话总结： 个人 skills 放 ~/.claude/skills/，用不同的名字——和项目 skill 同名会导致遮蔽，这是唯一的真实风险。