主题
08.6 Skill 实战示例集
4 个可直接复制、改改就能用的完整 Skill。
读完你能做什么：拿走这些模板，替换成你的项目细节，立刻拥有可用的技能。
示例 1：上线前检查（流程型）
场景：每次发版前的标准检查，最常见的 Skill 用途。
text
.claude/skills/release-check/
└── SKILL.mdmarkdown
---
name: release-check
description: 发版前的完整检查流程。当用户准备发布、部署、上线，或说
"要发版了""准备上线""能发布吗""release"时使用。
disable-model-invocation: true
---
# 发版前检查
依次执行，每项明确给出 ✅ 通过 / ❌ 不通过：
## 代码质量
1. 全部测试通过：`npm test`
2. 类型检查无错误：`npm run typecheck`
3. Lint 无错误：`npm run lint`
4. 无遗留调试代码：`grep -rn "console.log\|debugger\|TODO: remove" src/`
## 版本与文档
5. 版本号已更新（检查 package.json 的 version 是否比上个 tag 高）
6. CHANGELOG 已更新（对比 `git log $(git describe --tags --abbrev=0)..HEAD` 和 CHANGELOG）
## Git 状态
7. 无未提交改动：`git status --porcelain`
8. 当前在正确的发布分支上
## 输出
- 逐项列出结果
- 任何 ❌ 都要说清具体问题和修复建议
- 有任何 ❌ 时，结论是"暂不可发布"，并列出待办
- 全部 ✅ 才输出"可以发布"要点：disable-model-invocation: true 确保它只在你明确 /release-check 时运行，不会 Claude 自作主张。
示例 2：API 设计（资源型）
场景：按团队规范设计接口，规范内容较长，用第 3 层资源。
text
.claude/skills/api-design/
├── SKILL.md
├── reference/
│ ├── conventions.md
│ └── error-codes.md
└── templates/
└── endpoint.md.tmplSKILL.md：
markdown
---
name: api-design
description: 按本团队规范设计 REST API。当用户需要设计新接口、添加 endpoint、
或提到"设计 API""加个接口""新的 endpoint""RESTful"时使用。
---
# API 设计
## 必守规则（始终记住）
- 资源用复数名词：`/users`，不是 `/user`
- 版本在路径：`/v1/users`
- 分页用 `limit` + `cursor`，不用 offset
- 时间字段统一 ISO 8601 UTC
## 流程
1. 需要完整命名/结构规范时，读 `reference/conventions.md`
2. 用 `templates/endpoint.md.tmpl` 编写接口文档
3. 选错误码时查 `reference/error-codes.md`，不要自创错误码
## 读取原则
只读当前接口需要的参考章节，不要整篇读。reference/conventions.md（第 3 层，节选）：
markdown
# API 命名与结构规范
## URL 结构
- 集合：GET /v1/users
- 单个：GET /v1/users/{id}
- 子资源：GET /v1/users/{id}/orders
...
## 请求/响应
- 请求体用 snake_case
- 所有列表响应包裹在 { "data": [...], "next_cursor": "..." }
...示例 3：事故复盘（模板型）
场景：线上事故后生成标准复盘文档。
text
.claude/skills/postmortem/
├── SKILL.md
└── templates/
└── postmortem.md.tmplmarkdown
---
name: postmortem
description: 生成标准的事故复盘（postmortem）文档。当用户处理完线上故障、
需要复盘、或提到"复盘""事故报告""postmortem""RCA"时使用。
---
# 事故复盘
用 `templates/postmortem.md.tmpl` 的结构生成复盘文档。
## 采集信息（先问清楚，不要编）
如果用户没提供以下信息，先逐项询问，不要假设：
- 事故时间线（发现、定位、缓解、恢复各在几点）
- 影响范围（多少用户、哪些功能、持续多久）
- 根本原因（不是"XX 挂了"，而是"为什么 XX 会挂"）
## 原则
- 对事不对人：复盘针对系统和流程，不追究个人
- 每个"行动项"必须可执行、有负责人、有截止时间
- 区分"根本原因"和"触发条件"
## 输出
按模板生成，行动项部分用表格：| 行动 | 负责人 | 截止 | 防止哪类问题复发 |templates/postmortem.md.tmpl：
markdown
# 事故复盘：{TITLE}
- **日期**：{DATE}
- **严重度**：{SEVERITY}
- **影响时长**：{DURATION}
- **影响范围**：{IMPACT}
## 时间线
| 时间 | 事件 |
| :--- | :--- |
## 根本原因
{ROOT_CAUSE}
## 触发条件
{TRIGGER}
## 做得好的
{WHAT_WENT_WELL}
## 行动项
| 行动 | 负责人 | 截止 | 防止哪类问题 |
| :--- | :--- | :--- | :--- |示例 4：安全提交（带工具限制 + 隔离）
场景：一个受限的提交技能，只能跑 git，且不自动触发。
text
.claude/skills/safe-commit/
└── SKILL.mdmarkdown
---
name: safe-commit
description: 安全地暂存并提交当前改动，遵循团队 commit 规范。
disable-model-invocation: true
allowed-tools: Bash(git add *) Bash(git commit *) Bash(git status *) Bash(git diff *)
---
# 安全提交
## 流程
1. `git status` 和 `git diff` 查看改动
2. 分析改动，判断是否应该拆成多个 commit
3. 起草 commit message（conventional commits 格式）
4. **把 message 和拆分方案给我看，等我确认**
5. 确认后执行 git add + commit
## commit message 规范
- 格式：`type(scope): subject`
- type：feat/fix/refactor/test/docs/chore
- subject 用祈使句，≤ 50 字符
- body 说明"为什么"
## 约束
- 一个 commit 只做一件逻辑完整的事
- 不加任何 AI 署名
- 绝不 push（这个技能只负责本地提交）要点：
allowed-tools把能力锁死在 git 的几个安全子命令，即使被误用也跑不了别的disable-model-invocation: true确保只手动触发- 正文里的"等我确认"设了人工检查点
用这些示例的正确姿势
步骤 1：复制并本地化
把示例复制到你的 .claude/skills/，替换成你项目的实际命令、规范、路径。
步骤 2：打磨 description
按 08.3 的方法，把 description 改成匹配你团队实际的说法。
步骤 3：测试触发
text
> /reload-skills用几组"应触发/不应触发"的输入测一遍。
步骤 4：提交共享
bash
git add .claude/skills/
git commit -m "chore: add team skills"提交后全团队共享这些技能。要跨项目分发，打包成 Plugin，见 10.1。
用 Claude 帮你写 Skill
不想手写？让 Claude Code 的 skill-creator 帮你：
text
> 用 skill-creator 帮我创建一个技能：每次我说"日报"，
就汇总今天的 git 提交和我改动的文件，生成一份简短的工作日志。
帮我把 description 写得触发准确。