5.3 团队共享命令库

一个人写，所有人用

Skills 最大的价值不是让你自己省事，而是把团队的最佳实践编码化。

你们团队有代码审查规范？写成 /review。有固定的部署流程？写成 /deploy。有 release note 格式要求？写成 /changelog。

这些规范以前写在 Wiki 里，总是有人不看；写进 Skills，每次工作流自然就强制执行了。

把 Skills 放进版本控制

项目级 Skills 放在 .claude/skills/ 目录下，和代码一起 check in 到 git：

bash

# 提交 Skills 到版本控制
git add .claude/skills/
git commit -m "chore: add team Claude Code skills"
git push

团队其他成员 git pull 之后，这些命令立刻就可以用了——不需要安装任何东西，不需要额外配置。

让 Claude Code 帮你维护 Skills

有个很方便的做法：让 Claude Code 自己来更新 Skills。

当你发现某个命令的执行结果不够好的时候：

the /review skill is missing checks for our error handling conventions.
update .claude/skills/review.md to also check:
- all async functions have proper try/catch
- errors are logged before being rethrown
- user-facing error messages don't expose internal details

它会直接修改文件，你 review 一下，满意了就提交。

版本控制 Skills 的注意事项

不要在 Skills 里写敏感信息

Skills 文件会进 git 仓库，不要在里面写 API key、密码、内网地址这类东西。需要的话用环境变量，或者在 Skill 里说"从环境变量 $DEPLOY_KEY 读取"。

和 CLAUDE.md 一起维护

如果 CLAUDE.md 里的规范更新了，相关的 Skills 也要跟着更新，保持一致。可以在 Skill 文件里用 @CLAUDE.md 引用，避免重复：

markdown

---
name: review
description: Review code following our team standards
---

Review the staged changes.

Follow all standards defined in @CLAUDE.md.

Additionally check:
[Skill 特有的检查项...]

给 Skills 加上注释说明

当团队成员不知道某个命令是干什么的时候，他们可以输入 /help 或者直接看文件。在文件开头加个简短的说明：

markdown

---
name: deploy
description: Deploy to staging environment with pre-flight checks
---

<!-- 
使用场景：部署到 staging 之前
触发方式：/deploy 或 /deploy staging
注意：不用于生产环境，生产部署走 CI/CD
-->

[部署流程...]

建立团队 Skills 的好时机

不需要一开始就把所有流程都写成 Skills。最好的时机是当你第三次说同一段话的时候。

第一次：正常描述任务第二次：意识到这是个规律第三次：停下来，写成 Skill

这样积累出来的 Skills 都是真实需要的，而不是为了"有 Skills 而有 Skills"。

下一节，给你一套可以直接用的实用命令模板。

5.3 团队共享命令库 ​

一个人写，所有人用 ​

把 Skills 放进版本控制 ​

推荐的目录结构 ​

让 Claude Code 帮你维护 Skills ​

版本控制 Skills 的注意事项 ​

建立团队 Skills 的好时机 ​