CCClaude Code中文喂饭教程

第一个 Skill 实战：提交前审查

第一个 Skill 不要做自动修改。推荐从只读提交前审查开始，把 diff、敏感信息、测试结果和提交说明做成稳定流程。

Skill 适合沉淀重复流程。第一个 Skill 最推荐做“提交前审查”，因为它只读、低风险、每个项目都会用到。

目标：

让 CC 在提交前按固定清单检查 diff、无关文件、敏感信息、验证结果和提交说明。

第 1 步：先判断是否适合做 Skill

请判断“提交前审查”是否适合做成 Claude Code Skill。

要求：
1. 说明这个流程为什么适合复用。
2. 说明它应该只读还是修改文件。
3. 说明触发场景。
4. 说明不适合自动执行的动作。
5. 先不要创建文件，只输出判断。

如果 CC 建议自动提交、自动推送、自动修复全部问题，先拦住。第一个 Skill 只做审查。

Skill 和普通提示词的区别

普通提示词适合一次性任务。Skill 适合反复执行、流程固定、边界清楚的任务。

适合 Skill不适合 Skill
提交前审查临时需求
发布前检查一次性讨论
文档生成格式模糊探索
团队固定 Review 清单高风险自动执行

如果一个流程还没跑稳定，先不要急着做成 Skill。

为什么选提交前审查

原因说明
高频每个任务结束前都可能用
低风险可以只读，不需要改文件
价值明确能减少无关文件、密钥、漏验收
容易验证看输出是否能指导提交
适合团队输出格式可以统一

第 2 步：设计 SKILL.md 草稿

请设计一个 instruction-only Skill 草稿，名称叫 pre-commit-review。

用途：
提交前只读审查当前未提交改动。

要求：
1. 不修改文件。
2. 不执行 Git 写操作。
3. 检查 diff 是否有无关文件。
4. 检查是否有 API Key、Token、密码等敏感信息。
5. 检查是否有验证结果。
6. 输出提交说明建议。
7. 输出剩余风险。

请只输出 SKILL.md 草稿，不要创建文件。

第 3 步：审查草稿

Skill 草稿写完后，先审查。

请审查这个 Skill 草稿。

重点检查：
1. 是否保持只读。
2. 是否包含自动提交、自动推送、自动修复。
3. 输出格式是否清楚。
4. 是否会误导用户跳过人工审查。
5. 是否需要补充禁止事项。

只给修改建议，不要创建文件。

草稿必须有禁止事项

第一个 Skill 必须明确写：

第 4 步：低风险验证

不要拿真实大提交验证。可以用小改动或练习项目验证。

请按 pre-commit-review Skill 的流程模拟执行一次提交前审查。

要求：
1. 只读查看当前 diff。
2. 不修改文件。
3. 不执行 git add、commit、push。
4. 按 Skill 输出格式汇报。
5. 如果没有 diff，请说明如何用练习改动验证。

验证时看什么

检查项合格表现
是否只读没有修改文件和 Git
风险识别能发现敏感信息、无关文件、未验证项
输出格式固定且容易扫读
提交建议不夸大、不替用户提交
下一步能告诉用户是否还要补验收

推荐输出格式

一个好用的提交前审查 Skill，输出可以固定成这样：

## 变更范围
- 修改文件：
- 新增文件：
- 删除文件：

## 风险检查
- 无关改动：
- 敏感信息：
- 配置/部署影响：
- 数据库影响：

## 验证情况
- 已运行检查：
- 未验证内容：
- 建议补充检查：

## 提交建议
- 建议提交说明：
- 是否建议现在提交：
- 剩余风险：

不要让第一个 Skill 做这些

什么时候可以扩展这个 Skill

验证稳定后，可以逐步加：

每次扩展都要重新验证，不要一次塞太多规则。

扩展时一次只加一个能力

比如第一版只做 diff 和敏感信息检查。第二版再加提交说明格式。第三版再加项目专属检查。

每次扩展后都问：

请比较这个 Skill 扩展前后的差异。
新增能力是什么？
是否仍然保持只读？
是否引入自动提交、删除、修改等高风险动作？
输出是否仍然清晰？

Skill 收尾模板

请总结这个 pre-commit-review Skill 的使用结果。

请说明：
1. 它是否保持只读。
2. 它发现了哪些真实风险。
3. 输出格式是否够清楚。
4. 是否有误报或遗漏。
5. 下一版应该调整什么。

验收结果

下一篇：Hooks