3.9b Skills 困难关：找到和活用 Skill
预计耗时：15 分钟
本关任务简报
3.9a 讲了 Skill 是什么、怎么触发、文件结构是什么样的。这一关解决三个更实际的问题：
- 你不需要从零写——别的开发者已经公开分享了很多经过验证的高质量 Skill，找到并安装比自己造轮子快得多
- 有了需求，怎么系统地把它设计成一个好 Skill——五步设计法，从模糊想法到稳定可用
- 写出来了还不够准——测试矩阵帮你找到边界问题，迭代到真正可用
通关奖励：解锁以下技能
- 🌐 知道从哪里找别人写好的现成 Skill
- 🔧 能用五步设计法把一个模糊需求变成稳定可用的 Skill
- 📐 掌握 description 写法、边界清晰、参数活用等核心设计原则
- 🧪 能用测试矩阵系统验证 Skill 的行为
- 📦 了解通过 cc switch 和 GitHub 安装 Skill 的方法
开始前先检查装备
| 前置知识 | 说明 |
|---|---|
| 3.9a Skills 基础关 → | 了解 Skill 的工作原理、文件结构和触发方式——这是本关的基础 |
机制解析
去哪里找现成的 Skill
先说清楚一件事：所谓"现成的 Skill"，指的是其他开发者公开分享出来的 Skill——他们把自己打磨好的 SKILL.md 开源出来，主要发布在 GitHub 上；cc switch 的"发现技能"则把这些公开 Skill 做了聚合索引，方便搜索安装。下面三个入口，本质上都是在找这批"别人写好、可以直接拿来用"的 Skill。
入口一：cc switch"发现技能"（最省事）
打开 cc switch → 右上角扳手图标 → 发现技能，内置搜索覆盖了一批主流的公开 Skill。输入关键词（如 review、commit、test）过滤，点击一键安装。全程不碰命令行，适合大多数人。
入口二：在 GitHub 找到，让 Claude Code 帮你装
很多开发者会把 Skill 放在 GitHub 仓库里。在 GitHub 搜索 claude skill、claude code skill、claude code commands 等关键词就能找到。
找到之后不用自己手动克隆——Claude Code 已经装好了，直接把仓库地址丢给它，让它读取并保存到本地：
这是一个 Claude Code Skill 的 GitHub 仓库：https://github.com/<user>/<repo>
帮我看看它是做什么的，如果有用就把它的 SKILL.md 保存到
~/.claude/skills/<合适的名字>/SKILL.mdClaude 会读取仓库内容、确认它确实是个 Skill、再写到正确的位置。比手动 git clone 后还要自己核对目录结构方便得多，而且 Claude 顺手就能帮你判断这个 Skill 靠不靠谱、有没有可疑指令。装好后，如果 ~/.claude/skills/ 之前就存在，当前会话即时生效；只有第一次创建这个目录时才需重启一次，之后 / 补全里就能看到新命令。
如果你更习惯命令行，手动克隆也行：
git clone https://github.com/<user>/<repo> ~/.claude/skills/<name>。但克隆后要确认目录里确实有SKILL.md，且文件名是全大写。
入口三：ccswitch:// 深链
别人分享 Skill 时，有时会附带一个 ccswitch:// 开头的链接。点击后 cc switch 会自动完成下载、安装和同步，全程不用手动操作——这是最快的一种分享 / 安装方式。
五步设计法：从需求到可用 Skill
从零设计一个 Skill，按这五步走比凭感觉乱写要稳得多：
第一步：明确需求
在动手之前先回答四个问题：
- 这个 Skill 解决什么具体问题？
- 触发条件是什么（什么情况下用户会想到用它）？
- 成功的标准是什么（输出什么算对）？
- 边界在哪里（什么情况下不该用它）？
第二步：确定名字
- 简短，用 kebab-case（小写 + 连字符）
- 反映核心动作，如
review-pr、gen-commit、sql-debug - 避免过于通用的名字（
helper、tool），也避免过于具体的名字（review-auth-module-v2）
第三步：写 description（最关键一步）
description 是触发机制的核心——写错了，Skill 要么总是触发，要么从不触发。
参考模板："[核心能力]，适用于 [具体场景]，不适用于 [边界案例]"
| description | 问题 | |
|---|---|---|
| ❌ | 帮我处理代码 | 过于宽泛，几乎任何任务都能匹配 |
| ❌ | 代码审查 | 缺少场景和边界信息 |
| ✅ | 审查当前分支改动里的安全漏洞（SQL 注入、XSS、未校验输入），输出 [HIGH/MED/LOW] 级别的问题报告；不适用于性能优化或代码风格检查 | 能力清晰、场景具体、边界明确 |
第四步：写指令正文
规范的正文结构包含四个要素，缺一会让行为不稳定：
# ✅ 规范写法
你是一个专注于安全的代码审查员。
当触发时：
1. 读取 $ARGUMENTS 指定的文件（默认：`!git diff --staged`）
2. 按 SQL 注入 / XSS / 未校验输入 / 敏感信息泄露四个类别检查
3. 每个问题以 [HIGH/MED/LOW] 开头，注明文件名和行号，给出修改建议
4. 最后汇总：发现 X 个高危、Y 个中危、Z 个低危问题
# ❌ 模糊写法
帮我审查代码，给出反馈。第五步：系统测试
写好之后别直接发布，先跑四类测试：
| 测试类型 | 验证什么 | 例子 |
|---|---|---|
| 触发测试 | 在 3+ 个正向场景下能正确激活 | 暂存了代码 → 运行 /review → 触发 |
| 边界测试 | 不相关任务不会误触发 | 问"帮我写个函数" → 不应该触发 review Skill |
| 输出测试 | 格式和内容符合 description 的承诺 | 输出里有 [HIGH/MED/LOW] 标记 |
| 边缘情况 | 空参数、文件不存在、没有暂存时不崩溃 | 没有暂存任何文件 → 触发 → 给出提示而不是报错 |
活用 $ARGUMENTS：一个 Skill 多种用法
同一个 Skill 通过参数支持不同调用方式，让受众更广：
---
name: review
description: 审查代码安全漏洞。不传参数时审查所有暂存区改动；传文件路径时只审查该文件
---
$ARGUMENTS 如果不为空，则只审查指定路径：
- 有路径时：运行 `!cat $ARGUMENTS`
- 无路径时：运行 `!git diff --staged`
...使用时：
/review # 审查所有暂存改动
/review src/auth/login.ts # 只审查登录模块让 Claude Code 帮你设计 Skill
把需求告诉 Claude Code，让它帮你生成 Skill 内容比从头手写快得多。有了五步设计法的思路，描述需求时更有针对性：
我需要一个 Skill，完成以下任务：
场景：每次开始写代码前做需求拆解
触发条件：用户描述了一个功能需求
输入：通过 $ARGUMENTS 传入需求描述
执行步骤：
1. 分析需求
2. 拆分成 3-5 个独立的可测试子任务
3. 每个子任务估算工作量（小/中/大）
4. 建议从哪个子任务开始，说明理由
输出格式：结构化列表
帮我在 ~/.claude/skills/task-breakdown/SKILL.md 里创建这个 Skill，
注意写清楚 description，要包含适用场景和边界。Claude 会生成完整的 SKILL.md，你再用它自己写的 Skill 测试一遍。发现问题继续迭代——这比自己从头做指令工程高效得多。
常见翻车原因
| 现象 | 根本原因 | 修复方法 |
|---|---|---|
| 每次都触发，不管问什么 | description 太宽泛 | 加上边界限制：不适用于... |
| 怎么都触发不了 | description 太具体或有歧义 | 扩展触发场景描述 |
| 同时有两个 Skill 抢着触发 | 两个 Skill 的 description 语义重叠 | 明确区分各自的适用边界 |
| 触发了但行为乱 | 指令正文缺少角色 / 步骤 / 输出格式说明 | 按四要素补全正文 |
| references/ 里的文件读不到 | 文件路径写错 | 使用相对于 SKILL.md 的路径 |
安装后管理
通过任意方式安装的 Skill，都可以在 cc switch 的 Skills 管理页面里统一管理：
- 查看所有 Skill 的同步状态（已同步哪些工具）
- 一键切换某个 Skill 的同步状态
- 从备份恢复
开始闯关
目标：用五步设计法创建一个实际有用的 Skill，并完整测试一遍。
第 1 步：找一个你真正需要的场景
回想一下：你最近对 Claude 重复说过哪些相似的指令？把它写成一句话，回答这四个问题：
- 解决什么问题？
- 触发条件是什么？
- 成功标准是什么？
- 边界在哪里？
第 2 步：用对话把需求结构化，让 Claude 生成 Skill
按上面"让 Claude Code 帮你设计"的格式描述需求，让 Claude 在 ~/.claude/skills/<命令名>/SKILL.md 创建 Skill。
第 3 步：运行测试矩阵
对新创建的 Skill 跑这四类测试（若你刚第一次创建 skills 目录，先重启一次让它被监听到）：
- 触发测试：在 3 个正向场景下触发
- 边界测试：在 1-2 个不相关场景里确认不误触发
- 输出测试：验证格式和内容符合预期
- 边缘情况：测试参数为空、文件不存在等异常情况
第 4 步：迭代
把测试里发现的问题记下来，描述给 Claude：
/my-skill 的结果有以下问题：[具体哪里不对]
请修改 ~/.claude/skills/my-skill/SKILL.md，改进这个地方。
特别注意：[你最在意的那个点]重复 2-3 轮迭代直到满意。
第 5 步：发现别人写好的 Skill
打开 cc switch → 发现技能，搜索和你场景相关的关键词，安装一个别人写好的试试，和你自己设计的对比看看有什么差异。
通关检定
- [ ] 知道找现成 Skill 的三个入口（cc switch / GitHub / ccswitch://）
- [ ] 能说出五步设计法的五个步骤
- [ ] 理解为什么 description 是最关键的字段，以及模糊 description 会带来什么问题
- [ ] 至少做了一次"触发 → 发现问题 → 迭代 description 或正文"的反馈循环
- [ ] 知道通过 cc switch 可以统一管理所有 Skill 的跨工具同步状态
全部点亮就算通关 ✓
卡关了？翻车指南在这
找了别人写的 Skill，安装后触发行为很奇怪
别人写的 Skill 质量参差不齐。遇到行为异常，先让 Claude 解释它理解的 Skill 内容：
你知道 /xxx 这个 Skill 是做什么的吗？请详细解释它的触发条件和执行步骤。如果理解和你的预期不一致，直接编辑 ~/.claude/skills/<name>/SKILL.md 修改指令。
让 Claude 生成了 Skill，但改了多次还是不准
通常是指令描述本身有歧义。换个方法：先在普通对话里手动把这个任务做一遍，让 Claude 记录下每一步它是怎么做的，然后把这个"操作记录"作为 Skill 的指令蓝本。具体的步骤描述比抽象的功能描述更有效。
Skill 里有步骤依赖外部工具（如特定命令行工具）
在 Skill 正文的开头加一步检查：
首先确认工具可用：
- 运行 `!which <工具名>` 检查工具是否存在
- 如果不存在，告知用户需要先安装 <工具名> 再使用本 Skill这样遇到工具缺失时能给出明确提示，而不是在中途报奇怪的错误。
Skill 触发了，但 $ARGUMENTS 没生效
在 SKILL.md 里加一步调试：
首先输出你收到的 $ARGUMENTS 值，然后继续执行。触发一次，确认参数有没有正确传入。如果参数为空，检查调用方式是否正确（/my-skill 参数内容，中间有空格）。
下一关
Skill 让你的工作流模块化、可复用，下一关把这个思路用在最高频的场景：把 Git 工作流和 Claude Code 深度打通，自动生成 commit message、做 PR 代码审查。