Skill 是 Claude Code 生态里「写一次、永久生效」的能力资产。这篇指南讲清楚:它怎么被触发、怎么写才真的生效、以及 7 个最常见的失败写法。
一个 skill 就是一个带说明书的目录,核心是一个 SKILL.md 文件。它与三种老方式的区别:
| 方式 | 问题 | Skill 解决了什么 |
|---|---|---|
| 每次打字交代 | 同样的要求重复几十遍,版本漂移 | 交代一次,永久生效 |
| 写进 CLAUDE.md | 所有规则常驻上下文,互相干扰,token 浪费 | 按需加载——用到才读 |
| MCP 工具 | 解决「能力」,不解决「做法」 | skill 是「做法」:步骤、标准、禁区 |
一句话:MCP 给 Claude 新的手,skill 教它新的脑。
my-skill/
└── SKILL.md
SKILL.md 由两部分构成:frontmatter(机器读) + 正文(Claude 干活时读)。
---
name: code-review-checklist
description: 七维度系统化审查代码改动。MUST USE when 用户要求 review 代码、审查 PR、检查 diff、code review、"帮我看看这段代码对不对"。关键词:代码审查、review、PR、diff。
---
# 代码审查清单
## Workflow
1. 先读 diff 全貌,理解意图再挑错
2. 按七个维度逐项检查:正确性/安全/性能/契约/错误处理/测试/可维护性
3. 每个发现必须附 file:line 和具体修法
## Output
按 Blockers / Should-fix / Nits 三级输出,末尾给 Verdict
## Anti-patterns
- 禁止只说 "Looks good" 的盖章式审查
- 禁止报风格问题占用 blocker 位置
Claude 平时不加载你的 skill 正文,它只看每个 skill 的 description 来决定「现在要不要用」。所以 description 写砸了,正文再好也永远沉睡。
description: 【做什么】+ 【MUST USE when 触发场景】+ 【用户会说的原话关键词】
| ❌ 沉睡写法 | ✅ 会被触发 |
|---|---|
Helps with code quality | 七维度审查代码改动。MUST USE when 用户要求 review、审查 PR、检查 diff、看看代码有没有问题 |
Git commit helper | 拆分逻辑提交并写规范 commit message。MUST USE when 用户要提交代码、写 commit、说 "commit this" |
经验上最有效的三段式(不是理论,是踩坑后的结论):
| # | 错误 | 修法 |
|---|---|---|
| 1 | description 含糊("improve coding") | 套第 3 节公式,写用户原话 |
| 2 | 一个 skill 管五件事 | 拆开。触发条件越单一,命中率越高 |
| 3 | 正文是提示词堆砌,没有步骤 | 改成编号 Workflow |
| 4 | 没有输出格式约定 | 规定分级/表格/必填字段 |
| 5 | 没有 Anti-patterns 段 | 至少写 2-3 条硬禁区 |
| 6 | 中英文关键词只写一种 | 双语都写(说 "review" 和说 "审查" 的是同一个人) |
| 7 | 写完不测 | 下一节:三个测试用例 |
帮我看看这次改动有没有问题),看 skill 是否被加载。没触发 → 回去改 description。# 用户级(所有项目可用)
my-skill/SKILL.md → ~/.claude/skills/my-skill/SKILL.md
# 项目级(随仓库走,团队共享)
my-skill/SKILL.md → <repo>/.claude/skills/my-skill/SKILL.md
项目级是团队规范对齐的利器:skill 进了仓库,全团队的 Claude 自动同频。
本文的写法原则来自一个 15 个 skill 的工程包——pr-reviewer / bug-hunter / test-forge / feature-spec / commit-craft 这 5 个在 GitHub 上以 MIT 开源,可以直接当模板改: