Claude Code的使用小技巧:Skills与Commands
相信各位佬友现在已经或多或少使用过skills并且创建了更好用更合适的协助式skills,今天我以我个人这几天在简单使用中来小小的总结一下skills和commands
Skills的使用:
1. skills的基本要素:
首先skills分为用户级与项目级,两者的存放位置如下,仅需要把你想要下载的skills放在下面的目录中,cc在每次对话开始前就会自动识别并加载用户级与项目级的skills,并且可以用/{skill-name}的方式调用或者根据你的上下文内容自动调用skills:
- 用户级:
~/.claude/skills/用户级的skills全局生效,可以在任何目录中调用用户级skills - 项目级:
<项目根目录>/.claude/skills/项目级skills仅在当前项目生效,适合针对该项目做专业的工作
skills的一般目录结构如下,以官方的skill-creator中的SKILL.md中的内容为例
skill-name/
├── SKILL.md(必需)
│ ├── YAML frontmatter 元数据(必需)
│ │ ├── name:(必需)
│ │ └── description:(必需)
│ └── Markdown 指令(必需)
└── 捆绑资源(可选)
├── scripts/ # 可执行代码(Python/Bash 等)
├── references/ # 需要时加载到上下文的文档
└── assets/ # 用于输出的文件(模板、图标、字体等)
在官方的skill-creator中的SKILL.md中介绍了每个skill所需要的内容
-
YAML frontmatter: Claude会通过上下文中的内容匹配description中的应用场景来触发skill,或者通过/skillname {描述}l来触发,需要简短并全面的描述整个skill的功能和应用场景。--- name: <skill-name> description: <简要说明技能功能>。当用户请求"<触发短语1>"、"<触发短语2>"、"<触发短语3>",或涉及<相关领域/任务>时,使用此技能。 --- -
references/:在加载skill时会一并加载到上下文中来作为补充思考的参考资料,通常是执行一个skill中多个模式时的参考资料补充,也可以是每个模式具体的流程。 -
scripts/:skill可以包含脚本,可以变成一个主动触发的小型MCP服务,一些重复性或者规定格式文件生成工作可以以脚本的形式写在skill中,比如你可以让它读取数据库指定表并按照模板自动生成全后端的CRUD代码。 -
assets/:静态的文件,图像、logo等等,这个应该是写一些前端代码生成时用到的东西,目前我还没用到过。
---
name: skill-creator
description: 创建高效技能的指南。当用户想要创建新技能(或更新现有技能)以扩展 Claude 的能力时,应使用此技能,包括专业知识、工作流程或工具集成。
license: 完整条款见 LICENSE.txt
---
# 技能创建器
本技能提供创建高效技能的指导。
## 关于技能
技能是模块化、自包含的软件包,通过提供专业知识、工作流程和工具来扩展 Claude 的能力。可以将它们视为特定领域或任务的"入职指南"——它们将 Claude 从通用代理转变为配备程序性知识的专业代理,而这些知识是任何模型都无法完全具备的。
### 技能提供的内容
1. 专业工作流程 - 特定领域的多步骤程序
2. 工具集成 - 处理特定文件格式或 API 的指令
3. 领域专业知识 - 公司特定知识、数据模式、业务逻辑
4. 捆绑资源 - 用于复杂和重复任务的脚本、参考资料和资产
## 核心原则
### 简洁至上
上下文窗口是公共资源。技能与 Claude 所需的其他所有内容共享上下文窗口:系统提示、对话历史、其他技能的元数据以及实际的用户请求。
**默认假设:Claude 已经非常智能。** 只添加 Claude 尚不具备的上下文。对每条信息提出质疑:"Claude 真的需要这个解释吗?"以及"这段内容值得消耗这些 token 吗?"
优先使用简洁的示例,而非冗长的解释。
### 设置适当的自由度
根据任务的脆弱性和可变性匹配具体程度:
**高自由度(基于文本的指令)**:当多种方法都有效、决策取决于上下文或启发式方法指导方案时使用。
**中等自由度(伪代码或带参数的脚本)**:当存在首选模式、可接受一定变化或配置影响行为时使用。
**低自由度(特定脚本,少量参数)**:当操作脆弱且容易出错、一致性至关重要或必须遵循特定顺序时使用。
将 Claude 想象为探索一条路径:悬崖边的窄桥需要特定的护栏(低自由度),而开阔的田野允许多条路线(高自由度)。
### 技能的结构
每个技能由一个必需的 SKILL.md 文件和可选的捆绑资源组成:
```
skill-name/
├── SKILL.md(必需)
│ ├── YAML frontmatter 元数据(必需)
│ │ ├── name:(必需)
│ │ └── description:(必需)
│ └── Markdown 指令(必需)
└── 捆绑资源(可选)
├── scripts/ - 可执行代码(Python/Bash 等)
├── references/ - 需要时加载到上下文的文档
└── assets/ - 用于输出的文件(模板、图标、字体等)
```
#### SKILL.md(必需)
每个 SKILL.md 包含:
- **Frontmatter**(YAML):包含 `name` 和 `description` 字段。这是 Claude 用来判断何时使用技能的唯一字段,因此清晰全面地描述技能是什么以及何时应该使用它非常重要。
- **Body**(Markdown):使用技能的指令和指导。仅在技能触发后加载(如果触发的话)。
#### 捆绑资源(可选)
##### 脚本(`scripts/`)
用于需要确定性可靠性或反复重写的任务的可执行代码(Python/Bash 等)。
- **何时包含**:当相同的代码被反复重写或需要确定性可靠性时
- **示例**:用于 PDF 旋转任务的 `scripts/rotate_pdf.py`
- **优点**:节省 token、确定性、可以在不加载到上下文的情况下执行
- **注意**:脚本可能仍需要被 Claude 读取以进行修补或环境特定调整
##### 参考资料(`references/`)
需要时加载到上下文中以指导 Claude 流程和思考的文档和参考材料。
- **何时包含**:用于 Claude 在工作时应参考的文档
- **示例**:用于财务模式的 `references/finance.md`、用于公司保密协议模板的 `references/mnda.md`、用于公司政策的 `references/policies.md`、用于 API 规范的 `references/api_docs.md`
- **用例**:数据库模式、API 文档、领域知识、公司政策、详细工作流程指南
- **优点**:保持 SKILL.md 精简,仅在 Claude 确定需要时加载
- **最佳实践**:如果文件较大(>10k 词),在 SKILL.md 中包含 grep 搜索模式
- **避免重复**:信息应该存在于 SKILL.md 或参考文件中,而不是两者都有。除非信息确实是技能的核心,否则优先将详细信息放在参考文件中——这样可以保持 SKILL.md 精简,同时使信息可发现而不占用上下文窗口。仅在 SKILL.md 中保留基本的程序性指令和工作流程指导;将详细的参考材料、模式和示例移至参考文件。
##### 资产(`assets/`)
不打算加载到上下文中,而是用于 Claude 产出的输出中的文件。
- **何时包含**:当技能需要将在最终输出中使用的文件时
- **示例**:用于品牌资产的 `assets/logo.png`、用于 PowerPoint 模板的 `assets/slides.pptx`、用于 HTML/React 样板的 `assets/frontend-template/`、用于排版的 `assets/font.ttf`
- **用例**:模板、图像、图标、样板代码、字体、被复制或修改的示例文档
- **优点**:将输出资源与文档分离,使 Claude 能够使用文件而无需将其加载到上下文中
#### 技能中不应包含的内容
技能应仅包含直接支持其功能的必要文件。不要创建无关的文档或辅助文件,包括:
- README.md
- INSTALLATION_GUIDE.md
- QUICK_REFERENCE.md
- CHANGELOG.md
- 等等
技能应仅包含 AI 代理完成手头工作所需的信息。它不应包含关于创建过程的辅助上下文、设置和测试程序、面向用户的文档等。创建额外的文档文件只会增加混乱和困惑。
### 渐进式披露设计原则
技能使用三级加载系统来高效管理上下文:
1. **元数据(name + description)** - 始终在上下文中(约 100 词)
2. **SKILL.md body** - 当技能触发时(<5k 词)
3. **捆绑资源** - 根据 Claude 需要(无限制,因为脚本可以在不读入上下文窗口的情况下执行)
#### 渐进式披露模式
将 SKILL.md body 保持在必要内容且不超过 500 行,以最小化上下文膨胀。接近此限制时将内容拆分到单独的文件中。当将内容拆分到其他文件时,非常重要的是从 SKILL.md 引用它们并清楚描述何时读取它们,以确保技能的读者知道它们的存在以及何时使用它们。
**关键原则:** 当技能支持多种变体、框架或选项时,仅在 SKILL.md 中保留核心工作流程和选择指导。将特定变体的详细信息(模式、示例、配置)移至单独的参考文件。
**模式 1:带参考资料的高级指南**
```markdown
# PDF 处理
## 快速开始
使用 pdfplumber 提取文本:
[代码示例]
## 高级功能
- **表单填写**:完整指南见 [FORMS.md](FORMS.md)
- **API 参考**:所有方法见 [REFERENCE.md](REFERENCE.md)
- **示例**:常见模式见 [EXAMPLES.md](EXAMPLES.md)
```
Claude 仅在需要时加载 FORMS.md、REFERENCE.md 或 EXAMPLES.md。
**模式 2:领域特定组织**
对于具有多个领域的技能,按领域组织内容以避免加载不相关的上下文:
```
bigquery-skill/
├── SKILL.md(概述和导航)
└── reference/
├── finance.md(收入、计费指标)
├── sales.md(商机、管道)
├── product.md(API 使用、功能)
└── marketing.md(营销活动、归因)
```
当用户询问销售指标时,Claude 只读取 sales.md。
类似地,对于支持多个框架或变体的技能,按变体组织:
```
cloud-deploy/
├── SKILL.md(工作流程 + 提供商选择)
└── references/
├── aws.md(AWS 部署模式)
├── gcp.md(GCP 部署模式)
└── azure.md(Azure 部署模式)
```
当用户选择 AWS 时,Claude 只读取 aws.md。
**模式 3:条件性详情**
显示基本内容,链接到高级内容:
```markdown
# DOCX 处理
## 创建文档
使用 docx-js 创建新文档。见 [DOCX-JS.md](DOCX-JS.md)。
## 编辑文档
对于简单编辑,直接修改 XML。
**对于修订跟踪**:见 [REDLINING.md](REDLINING.md)
**对于 OOXML 详情**:见 [OOXML.md](OOXML.md)
```
Claude 仅在用户需要这些功能时读取 REDLINING.md 或 OOXML.md。
**重要指南:**
- **避免深层嵌套引用** - 保持引用从 SKILL.md 只有一层深度。所有参考文件应直接从 SKILL.md 链接。
- **结构化较长的参考文件** - 对于超过 100 行的文件,在顶部包含目录,以便 Claude 在预览时可以看到完整范围。
## 技能创建流程
技能创建包括以下步骤:
1. 通过具体示例理解技能
2. 规划可复用的技能内容(脚本、参考资料、资产)
3. 初始化技能(运行 init_skill.py)
4. 编辑技能(实现资源并编写 SKILL.md)
5. 打包技能(运行 package_skill.py)
6. 基于实际使用进行迭代
按顺序执行这些步骤,仅在有明确理由说明不适用时才跳过。
### 步骤 1:通过具体示例理解技能
仅当技能的使用模式已经清楚理解时才跳过此步骤。即使在处理现有技能时,此步骤仍然有价值。
要创建有效的技能,需要清楚理解技能将如何使用的具体示例。这种理解可以来自直接的用户示例或经过用户反馈验证的生成示例。
例如,在构建图像编辑器技能时,相关问题包括:
- "图像编辑器技能应该支持什么功能?编辑、旋转,还有其他吗?"
- "你能给出一些这个技能将如何使用的示例吗?"
- "我可以想象用户会要求'去除这张图片的红眼'或'旋转这张图片'。你还能想象这个技能的其他使用方式吗?"
- "用户说什么应该触发这个技能?"
为避免让用户不知所措,避免在单条消息中问太多问题。从最重要的问题开始,根据需要跟进以获得更好的效果。
当对技能应支持的功能有清晰认识时,结束此步骤。
### 步骤 2:规划可复用的技能内容
要将具体示例转化为有效的技能,通过以下方式分析每个示例:
1. 考虑如何从头开始执行示例
2. 识别在反复执行这些工作流程时哪些脚本、参考资料和资产会有帮助
示例:在构建 `pdf-editor` 技能以处理"帮我旋转这个 PDF"等查询时,分析显示:
1. 旋转 PDF 每次都需要重写相同的代码
2. 在技能中存储 `scripts/rotate_pdf.py` 脚本会有帮助
示例:在设计 `frontend-webapp-builder` 技能以处理"给我构建一个待办事项应用"或"给我构建一个跟踪步数的仪表板"等查询时,分析显示:
1. 编写前端 webapp 每次都需要相同的 HTML/React 样板
2. 在技能中存储包含样板 HTML/React 项目文件的 `assets/hello-world/` 模板会有帮助
示例:在构建 `big-query` 技能以处理"今天有多少用户登录?"等查询时,分析显示:
1. 查询 BigQuery 每次都需要重新发现表模式和关系
2. 在技能中存储记录表模式的 `references/schema.md` 文件会有帮助
要确定技能的内容,分析每个具体示例以创建要包含的可复用资源列表:脚本、参考资料和资产。
### 步骤 3:初始化技能
此时,是时候实际创建技能了。
仅当正在开发的技能已经存在且需要迭代或打包时才跳过此步骤。在这种情况下,继续下一步。
从头创建新技能时,始终运行 `init_skill.py` 脚本。该脚本方便地生成一个新的模板技能目录,自动包含技能所需的一切,使技能创建过程更加高效和可靠。
用法:
```bash
scripts/init_skill.py <skill-name> --path <output-directory>
```
该脚本:
- 在指定路径创建技能目录
- 生成带有正确 frontmatter 和 TODO 占位符的 SKILL.md 模板
- 创建示例资源目录:`scripts/`、`references/` 和 `assets/`
- 在每个目录中添加可以自定义或删除的示例文件
初始化后,根据需要自定义或删除生成的 SKILL.md 和示例文件。
### 步骤 4:编辑技能
在编辑(新生成或现有的)技能时,请记住技能是为另一个 Claude 实例使用而创建的。包含对 Claude 有益且非显而易见的信息。考虑什么程序性知识、领域特定细节或可复用资产将帮助另一个 Claude 实例更有效地执行这些任务。
#### 学习经过验证的设计模式
根据技能需求查阅这些有用的指南:
- **多步骤流程**:见 references/workflows.md 了解顺序工作流程和条件逻辑
- **特定输出格式或质量标准**:见 references/output-patterns.md 了解模板和示例模式
这些文件包含有效技能设计的既定最佳实践。
#### 从可复用技能内容开始
要开始实现,从上面确定的可复用资源开始:`scripts/`、`references/` 和 `assets/` 文件。请注意,此步骤可能需要用户输入。例如,在实现 `brand-guidelines` 技能时,用户可能需要提供品牌资产或模板存储在 `assets/` 中,或文档存储在 `references/` 中。
添加的脚本必须通过实际运行来测试,以确保没有错误且输出符合预期。如果有许多类似的脚本,只需测试具有代表性的样本,以确保它们都能工作,同时平衡完成时间。
任何技能不需要的示例文件和目录都应删除。初始化脚本在 `scripts/`、`references/` 和 `assets/` 中创建示例文件以演示结构,但大多数技能不需要所有这些。
#### 更新 SKILL.md
**写作指南:** 始终使用祈使句/不定式形式。
##### Frontmatter
编写包含 `name` 和 `description` 的 YAML frontmatter:
- `name`:技能名称
- `description`:这是技能的主要触发机制,帮助 Claude 理解何时使用该技能。
- 包括技能做什么以及何时使用它的具体触发器/上下文。
- 将所有"何时使用"信息放在这里 - 不要放在 body 中。body 仅在触发后加载,因此 body 中的"何时使用此技能"部分对 Claude 没有帮助。
- `docx` 技能的示例描述:"全面的文档创建、编辑和分析,支持修订跟踪、批注、格式保留和文本提取。当 Claude 需要处理专业文档(.docx 文件)时使用,用于:(1) 创建新文档,(2) 修改或编辑内容,(3) 处理修订跟踪,(4) 添加批注,或任何其他文档任务"
不要在 YAML frontmatter 中包含任何其他字段。
##### Body
编写使用技能及其捆绑资源的指令。
### 步骤 5:打包技能
技能开发完成后,必须将其打包成可分发的 .skill 文件与用户共享。打包过程会自动先验证技能以确保它满足所有要求:
```bash
scripts/package_skill.py <path/to/skill-folder>
```
可选的输出目录指定:
```bash
scripts/package_skill.py <path/to/skill-folder> ./dist
```
打包脚本将:
1. **自动验证**技能,检查:
- YAML frontmatter 格式和必需字段
- 技能命名约定和目录结构
- 描述的完整性和质量
- 文件组织和资源引用
2. 如果验证通过则**打包**技能,创建以技能命名的 .skill 文件(例如 `my-skill.skill`),包含所有文件并保持正确的目录结构以供分发。.skill 文件是带有 .skill 扩展名的 zip 文件。
如果验证失败,脚本将报告错误并退出而不创建包。修复任何验证错误并再次运行打包命令。
### 步骤 6:迭代
测试技能后,用户可能会要求改进。这通常发生在使用技能后不久,对技能表现有新鲜的上下文。
**迭代工作流程:**
1. 在实际任务中使用技能
2. 注意困难或低效之处
3. 确定应如何更新 SKILL.md 或捆绑资源
4. 实施更改并再次测试
2. skill的下载与快速创建
你可以在各类网站上找到你相中的skills,然后直接把他们下载下来放在你的用户级或者项目集的skills/目录中就可以了,你也可以直接用cc-switch来下载用户级的skills
CC-Switch 下载skills


一些skills网站(站内搜索skills就有很多分享的啦)
- https://linux.do/t/topic/1083630/1
- http://skillshunt.io/
- https://linux.do/t/topic/1416674/11
- https://linux.do/t/topic/1378927
- https://linux.do/t/topic/1416674/22
- https://github.com/huifer/skill-security-scan
- https://linux.do/t/topic/1416674/28
- https://github.com/OthmanAdi/planning-with-files
- https://github.com/anthropics/skills
- https://linux.do/t/topic/1390975
快速创建:
首先安装官方的skill-creator,这里需要注意的是windows的cli中默认编码是GBK,所以可能会遇见脚本执行编码错误的情况,直接让cc帮你修复,也可以直接下载这个修复后的skill
skill-creator.zip (20.5 KB)
安装好skill-creator后一定要重启cc让它加载好这个skill,然后直接/skill-creator 帮我创建一个项目级的{什么什么功能}的skill然后cc就一顿操作猛如虎给你建好了,肯定少不了一顿改来改去的,所以一般都是拿现成的过来用。
创建好后的skills在正确加载后执行/skills命令是会显示的:

甚至还有一个mcp-builder可以帮你创建mcp服务,我就拿他创建了一个可以连接mysql的mcp,还是挺方便的,总之我觉得skills可以理解为各种各样的插件,你缺什么功能了你就拿过来,还是挺有趣的。
Commands的使用
1. commands的基本介绍
commands可以理解为纯提示词版的skills(貌似cc加载的时候也会把自定义的commands当作skills加载?调用/skills可以看到创建的skills和commands)一般内容都是些工作流程的约束,比如项目分析、解释代码、审查代码等简单工作流程,也分为用户级与项目级,但是cc不会根据上下文来自动调用,而是需要手动调用/{command-name} 阿巴阿巴
- 用户级:
~/.claude/commands/全局生效 - 项目级:
<项目根目录>/.claude/commands/
commands的目录结构(支持命名空间):
.claude/commands/
├── code/
│ ├── explain-code.md # /code:explain-code
│ └── review-code.md # /code:review-code
└── analysis/
└── analyze-project.md # /analysis:analyze-project
正确加载后的样子

在commands中同样也会要求规定YAML frontmatter(非必需)
---
description: "分析项目结构和技术栈"
allowed-tools: ["read", "grep", "bash", "glob"]
model: sonnet
---
description:命令描述。allowed-tools:允许调用的工具。model:指定的模型。
2. commands的快速创建
commands的创建目前好像没有相应的skills支持(也可以使用skill-creator来创建一个commands-builder :tieba_003: ),但我们依然可以拜托万能cc帮我们创建,他自己知道commands的规则,直接让它创建一个项目级的分析代码commands即可。
貌似也可以在commands的工作流程中让其调用多个skills和mcp协作,实现一个完整的大型工作流程,这个我目前没试过,现在日常的代码工作应该够用了。
如果佬们想要体验更牛逼的协作功能可以体验一下站内大佬做的项目