SKILL.md语法详解:手把手教你写第一个Skill文件

什么?你连SKILL.md是什么都不知道?没关系,这篇文章就是为零基础小白写的。看完之后,你不仅能看懂SKILL.md文件,还能自己写一个出来。准备好了吗?let’s go!

这篇文章解决什么问题

学完这篇,你将能够:

  • 理解SKILL.md文件的整体结构
  • 掌握frontmatter的每个字段是什么意思、怎么写
  • 学会写instructions(核心指令部分)
  • 学会添加examples(示例)
  • 理解tools字段的作用
  • 独立写出一个完整的Skill文件

整个过程会很长,但别怕,我会用大白话解释每一个概念,并配上可以直接抄的示例代码。


第一部分:先搞清楚SKILL.md长什么样

1.1 SKILL.md到底是什么

首先,.md是Markdown文件的扩展名,你平时写的README.md、笔记.md都是这种格式。所以SKILL.md本质上就是一个Markdown文件,只是它的内容要遵循特定的格式规范。

那”SKILL.”前缀是什么意思呢?这其实是我们的命名约定——所有Skill定义文件都以SKILL.开头,这样一眼就能认出这是什么东西。比如:

  • SKILL.code-reviewer.md - 代码审查技能
  • SKILL.email-writer.md - 写邮件技能
  • SKILL.data-analyst.md - 数据分析技能

文件里写的东西,就是告诉AI:“当你遇到XX情况时,你应该怎么做”。

1.2 SKILL.md文件的整体结构

一个SKILL.md文件分两大部分:

┌─────────────────────────────────────────────────────────────┐
│                    SKILL.md 文件结构                         │
├─────────────────────────────────────────────────────────────┤
│  第一部分:frontmatter(文件开头的YAML配置)                  │
│  ┌───────────────────────────────────────────────────────┐  │
│  │ ---                                                   │  │
│  │ name: 技能名称                                         │  │
│  │ description: 一句话描述                                │  │
│  │ trigger: [触发词1, 触发词2]                             │  │
│  │ version: 1.0.0                                        │  │
│  │ ...                                                   │  │
│  │ ---                                                   │  │
│  └───────────────────────────────────────────────────────┘  │
│                                                             │
│  第二部分:正文内容(Markdown格式的指令)                       │
│  ┌───────────────────────────────────────────────────────┐  │
│  │ # 技能名称                                             │  │
│  │                                                         │  │
│  │ 你是一个XXX助手...                                      │  │
│  │                                                         │  │
│  │ ## 使用规则                                             │  │
│  │ 1. 当用户XXX时,你应该YYY                               │  │
│  │ 2. ...                                                 │  │
│  └───────────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────────┘

frontmatter(就是那三根横线围起来的部分)是给机器看的配置信息,告诉系统”这个Skill叫什么、有哪些属性”。

正文内容是给AI看的指令,告诉AI”当你被激活时,你应该怎么做”。

两者的关系可以这么理解:frontmatter像是身份证,正文像是个人简历。身份证告诉你这是谁,简历告诉你这个人会做什么。


第二部分:手把手写frontmatter

2.1 什么是frontmatter

frontmatter就是文件开头用---包裹的那段YAML代码。它叫”前置matter”,因为它放在文件最前面。

YAML是什么?简单说就是一种”人类容易读写、机器也容易解析”的数据格式。你不需要深究YAML的复杂语法,只需要知道:

  • key: value的形式来写
  • -来表示列表(数组)
  • ---开头和结尾来包裹

看个例子就懂了:

---
name: code-reviewer
description: 帮你审查代码问题
version: 1.0.0
---

这段YAML定义了一个Skill,它的名字是code-reviewer,描述是”帮你审查代码问题”,版本是1.0.0

2.2 必须掌握的字段

frontmatter里有几个字段是必须要写的,我们一个一个来看:

name字段:给Skill起个名字

name: skill-name

规则

  • 只能有:小写字母、数字、连字符(-)
  • 必须以字母开头
  • 不能有空格、不能有中文
  • 建议用功能描述性的名字
  • 整个系统里不能有重名的

好名字 vs 坏名字

# ✅ 好的名字
name: code-reviewer          # 小写+连字符,清晰表达功能
name: data-analyst           # 小写+连字符
name: email-composer         # 小写+连字符
 
# ❌ 坏的名字
name: CodeReviewer           # 有大写字母
name: code reviewer          # 有空格
name: code_reviewer          # 用下划线
name: 代码审查               # 用中文

description字段:告诉别人这个Skill干嘛的

description: 一句话描述这个Skill是干嘛的

要求

  • 一句话说完,不要啰嗦
  • 说清楚”做什么”,不用解释”怎么做”
  • 一般不超过50个字

例子

# ✅ 好的描述
description: 自动审查代码并提供改进建议
description: 根据用户需求生成专业邮件
description: 分析数据并生成可视化报告
 
# ❌ 不好的描述
description: 这个Skill可以帮你做很多事情  # 太模糊
description: 使用Python和机器学习算法对文本进行分析处理  # 太技术、太多细节

version字段:记录版本号

version: 1.0.0

版本号遵循”语义化版本”规则,格式是主版本.次版本.修订版本

  • 主版本:做了不兼容的大改
  • 次版本:新增了功能,但能向后兼容
  • 修订版本:修复了bug,小改动

对于初学者来说,直接写1.0.0就行,之后修改的时候记得更新这个数字。

2.3 常用的可选字段

除了上面的必填字段,还有一些经常用到的可选字段:

trigger字段:定义触发词

trigger就是激活这个Skill的”咒语”。当用户说的话里包含这些词时,系统就知道该用这个Skill了。

# 单个触发词
trigger: "代码审查"
 
# 多个触发词(任一个匹配就激活)
trigger:
  - "代码审查"
  - "检查代码"
  - "review code"
  - "看看代码有什么问题"

触发词设计原则

  1. 要具体,别用太泛的词。“处理”太泛,“处理图片”就清晰多了
  2. 要符合用户说话习惯。用户更可能说”帮我写个邮件”而不是”compose-email”
  3. 可以中英文都有,因为用户可能混着说

author字段:作者信息

# 简单写法
author: 张三
 
# 详细写法
author: "AI工具团队 <team@example.com>"

category和tags字段:分类和标签

这两个字段帮你组织管理多个Skills:

category:
  - 开发工具
  - 代码质量
 
tags:
  - javascript
  - 代码审查
  - 自动化

区别

  • category是层级分类,适合归大类
  • tags是扁平标签,适合多维度描述

requires字段:声明依赖

如果你的Skill需要用到其他Skill的能力,就在这里声明:

requires:
  - SKILL.code-formatter
  - SKILL.git-helper

系统加载你的Skill时,会自动先加载这些依赖。

tools字段:声明需要的工具

如果你的Skill需要调用外部工具(比如读写文件、执行命令),在这里声明:

tools:
  - file_reader
  - file_writer
  - terminal

2.4 frontmatter完整示例

把上面的字段组合起来,就是一个完整的frontmatter:

---
# ===== 身份信息(必须) =====
name: code-reviewer
description: 自动审查代码并提供改进建议
version: 1.0.0
 
# ===== 关联信息(推荐) =====
author: "AI工具团队 <team@example.com>"
category:
  - 开发工具
  - 代码质量
tags:
  - javascript
  - python
  - 代码审查
 
# ===== 行为配置(可选) =====
trigger:
  - "代码审查"
  - "review code"
  - "检查代码"
  - "看看代码问题"
 
requires:
  - SKILL.code-formatter
 
tools:
  - file_reader
  - terminal
 
# ===== 输出配置(可选) =====
output:
  format: markdown
  path: ./output
---

第三部分:写好正文内容(instructions)

3.1 instructions是什么

如果说frontmatter是”身份证”,那正文就是”个人简历”。正文里的内容是AI真正会看到和执行的指令。

在YAML语法里,instructions可以有几种写法。最常用的是用|符号表示多行文本:

instructions: |
  这里写的是指令内容
  可以写很多很多行
  AI会看到所有这些内容

3.2 instructions的基本结构

一个好的instructions通常包含以下几个部分:

第一步:定义角色

开篇第一句话,告诉AI”你是什么”。这叫做角色定义

instructions: |
  你是一个专业的代码审查助手。
  你有10年的编程经验,精通JavaScript、Python、Go等多种语言。
  你审查代码时注重:代码质量、安全性、性能、可维护性。

为什么角色定义很重要?

  • 设定角色会影响AI的”思考方式”和专业程度
  • 好的角色定义让AI的回答更专业、更符合预期

第二步:描述任务

告诉AI具体要做什么任务。

instructions: |
  当用户发送代码给你审查时,你应该:
 
  1. 首先理解代码的功能和目的
  2. 从以下维度进行审查:
     - 语法正确性
     - 代码风格
     - 潜在bug
     - 性能问题
     - 安全漏洞
  3. 对每个问题给出严重程度评级(高/中/低)
  4. 提供具体的改进建议

第三步:定义输出格式

告诉AI应该以什么格式输出结果。

instructions: |
  你的输出必须遵循以下格式:
 
  ## 代码审查报告
 
  ### 概述
  (简要说明这段代码是干什么的)
 
  ### 发现的问题
 
  #### 🔴 高危问题
  1. [问题描述]
     - 位置:xxx
     - 建议:xxx
 
  #### 🟡 中危问题
  ...
 
  #### 🟢 建议改进
  ...
 
  ### 总体评价
  (给出1-5分的评分和总结)

第四步:说明边界条件

告诉AI什么情况下应该拒绝、报错或特殊处理。

instructions: |
  ## 边界条件处理
 
  1. 如果用户发送的不是代码(比如是图片、纯文本):
     - 回复:"请发送需要审查的代码内容"
 
  2. 如果代码超过10000行:
     - 只审查前100行和最后100行
     - 提示用户:"代码较长,重点审查了首尾部分"
 
  3. 如果代码包含明显的恶意内容:
     - 拒绝审查
     - 回复:"这段代码包含可疑内容,无法进行审查"

3.3 写好instructions的技巧

技巧一:具体具体再具体

❌ 模糊的写法

instructions: |
  审查代码,给出建议。

✅ 具体的写法

instructions: |
  当用户发送代码时,从以下6个维度进行审查:
 
  1. 语法检查
     - 识别潜在的语法错误
     - 检查括号、引号是否匹配
 
  2. 风格检查
     - 变量命名是否清晰
     - 函数是否过长(超过50行提示拆分)
     - 是否有重复代码
 
  3. 逻辑检查
     - 条件判断是否完整
     - 循环是否有边界问题
 
  4. 安全检查
     - 是否有SQL注入风险
     - 是否有XSS漏洞
     - 敏感信息是否硬编码
 
  5. 性能检查
     - 是否有不必要的循环
     - 是否有效率低下的操作
 
  6. 最佳实践
     - 是否使用了推荐的写法
     - 是否有更优雅的实现方式

技巧二:用数字和列表明确步骤

人喜欢看列表,AI也喜欢。明确的步骤列表比大段描述更有效:

❌ 连续描述

instructions: |
  当用户发送代码时你应该首先理解代码功能,然后检查语法,接着分析逻辑,再检查安全问题,然后看看有没有性能问题,最后给出改进建议并以报告形式输出。

✅ 列表形式

instructions: |
  当用户发送代码时,按以下步骤执行:
 
  第一步:理解代码
  - 阅读代码注释和函数名,理解代码意图
  - 识别代码使用的语言和框架
 
  第二步:语法检查
  - 扫描语法错误
  - 检查括号、引号配对
 
  第三步:逻辑分析
  - 追踪主要执行流程
  - 识别潜在逻辑错误
 
  ...(以此类推)

技巧三:提供示例,让AI”照着做”

instructions的最后,可以加一个”输出示例”:

instructions: |
  ## 输出格式示例
 
  对于以下代码:
  ```python
  def add(a,b):
      return a+b

你的输出应该是:

## 代码审查报告

### 语法检查
✅ 没有发现语法错误

### 风格问题
⚠️ 函数名过短,建议使用更描述性的名称,如 `add_numbers`
⚠️ 参数缺少类型标注,建议添加类型注解

### 建议
- 添加文档字符串说明函数用途
- 考虑添加类型标注

### 评分
⭐⭐⭐☆☆ (3/5)

### 3.4 instructions高级技巧

#### 使用条件逻辑

```yaml
instructions: |
  根据用户输入的类型,采取不同的处理方式:

  如果用户发送的是:
  - JavaScript代码 → 使用JavaScript最佳实践进行审查
  - Python代码 → 使用Python最佳实践进行审查
  - 其他语言 → 使用通用编程原则进行审查

使用变量和占位符

instructions: |
  当你生成报告时,使用以下模板:
 
  报告标题:[技能名称] 审查报告 - [日期]
  审查范围:[输入代码的行数] 行代码
  发现问题数:高危 [N] 个,中危 [M] 个,建议 [K] 个

设置优先级和权重

instructions: |
  审查时按以下优先级进行:
 
  P0(必须检查):
  - 语法错误
  - 安全漏洞
 
  P1(重要检查):
  - 逻辑错误
  - 性能问题
 
  P2(建议检查):
  - 代码风格
  - 命名规范

第四部分:添加Examples(示例)

4.1 examples是什么

examples就是”参考答案”,给AI看几个”输入→输出”的例子,让AI知道”哦,原来要这样回答”。

4.2 什么时候需要examples

  • 当输出格式比较复杂时
  • 当边界情况需要特殊处理时
  • 当instructions描述不够清晰时

4.3 examples的写法

examples:
  - name: 简单函数审查
    description: 展示如何审查一个简单的加法函数
    input: |
      ```python
      def add(a, b):
          return a + b
      ```
    output: |
      ## 代码审查报告
 
      ### 语法检查
      ✅ 没有发现语法错误
 
      ### 建议改进
      1. **类型标注**:建议添加类型注解
         ```python
         def add(a: int, b: int) -> int:
             return a + b
         ```
 
      2. **文档字符串**:建议添加函数说明
         ```python
         def add(a: int, b: int) -> int:
             """返回两个数的和"""
             return a + b
         ```
 
      ### 评分
      ⭐⭐⭐☆☆ (3/5)

4.4 examples数量建议

  • 简单Skill:1-2个示例
  • 中等复杂度:3-5个示例
  • 复杂场景:5-8个示例

不要太多!示例太多反而可能导致过拟合(AI只会模仿示例,不会灵活发挥了)。


第五部分:完整SKILL.md文件示例

5.1 示例一:超级简单的打招呼Skill

这是你能写出的最简单的Skill:

---
name: greeting
description: 友好的打招呼助手
trigger:
  - "你好"
  - "早上好"
  - "hello"
version: 1.0.0
---
 
# 打招呼助手
 
你是一个友好的AI助手。
 
## 行为规则
 
当用户向你打招呼时,你应该:
1. 热情地回应
2. 询问有什么可以帮忙的
 
## 回复示例
 
用户说"你好"
→ 你回复"你好!很高兴见到你,今天过得怎么样?"
 
用户说"早上好"
→ 你回复"早上好!新的一天开始了,有什么计划吗?"

5.2 示例二:代码审查Skill

这是一个功能完整的代码审查Skill:

---
name: code-reviewer
description: 专业的代码审查助手
version: 1.0.0
author: "AI工具团队"
category:
  - 开发工具
  - 代码质量
tags:
  - 代码审查
  - JavaScript
  - Python
trigger:
  - "代码审查"
  - "检查代码"
  - "review code"
  - "帮我看看代码"
tools:
  - file_reader
output:
  format: markdown
---
 
# 代码审查助手
 
你是一个专业的代码审查助手,有10年编程经验,精通多种编程语言。
 
## 核心职责
 
当用户发送代码给你审查时,你应该:
1. 分析代码的功能和目的
2. 从多个维度进行审查
3. 给出具体的改进建议
4. 标注问题的严重程度
 
## 审查维度
 
### 1. 语法正确性
- 检查语法错误
- 检查括号、引号是否配对
 
### 2. 代码风格
- 变量和函数命名是否清晰
- 是否有适当的注释
- 是否遵循该语言的代码规范
 
### 3. 潜在Bug
- 边界条件处理
- 空指针/空值检查
- 异常处理
 
### 4. 性能问题
- 是否有不必要的循环
- 是否有效率低下的操作
 
### 5. 安全问题
- 是否有注入风险
- 敏感信息处理
- 权限控制
 
## 输出格式
 
你的输出必须遵循以下格式:
 

代码审查报告

📋 基本信息

  • 语言:[识别的编程语言]
  • 代码行数:[行数]

✅ 通过的检查

(列出没有问题的方面)

🔴 高危问题

  1. [问题描述]
    • 位置:[文件:行号或函数名]
    • 原因:[为什么会出问题]
    • 建议:[如何修复]

🟡 中危问题

🟢 建议改进

📊 总体评分

[1-5星评分]

💡 总结

[一句话总结]


## 边界情况

1. **非代码内容**:如果用户发送的不是代码
   → 回复:"请发送需要审查的代码内容,我只能审查代码哦~"

2. **代码过长**:如果代码超过500行
   → 回复:"代码较长,我可以审查关键部分。请告诉我重点想审查哪些部分?"

3. **恶意代码**:如果代码包含明显的恶意操作
   → 回复:"这段代码包含可疑操作,无法进行审查。如有安全问题,请咨询安全专家。"

## 示例

**用户输入**:
```python
def calc(a,b):
    return a+b

你的输出

## 代码审查报告

### 📋 基本信息
- 语言:Python
- 代码行数:2

### 🔴 高危问题
无

### 🟡 中危问题
无

### 🟢 建议改进
1. **函数命名**:建议使用更描述性的名称
   - 当前:`calc`
   - 建议:`add_numbers` 或 `calculate_sum`

2. **类型标注**:建议添加类型注解
   ```python
   def add_numbers(a: int, b: int) -> int:
       return a + b
  1. 文档字符串:建议添加函数说明
    def add_numbers(a: int, b: int) -> int:
        """返回两个数的和"""
        return a + b

📊 总体评分

⭐⭐⭐☆☆ (3/5)

💡 总结

代码功能正确,但缺少类型标注和文档,建议补充以提高可读性和可维护性。

5.3 示例三:邮件撰写Skill

---
name: email-writer
description: 专业邮件撰写助手
version: 1.0.0
author: "AI工具团队"
category:
  - 办公效率
tags:
  - 邮件
  - 写作
trigger:
  - "写邮件"
  - "帮我发邮件"
  - "起草邮件"
output:
  format: markdown
---
 
# 专业邮件撰写助手
 
你是一个专业的商务邮件撰写助手,擅长写清晰、专业、有礼貌的商业邮件。
 
## 工作流程
 
1. 理解用户想要表达的核心信息
2. 确定邮件的类型和语气
3. 按照邮件规范组织内容
4. 生成完整的邮件
 
## 邮件类型及语气
 
| 类型 | 语气 | 适用场景 |
|------|------|----------|
| 正式邮件 | 严谨、专业 | 商务往来、正式场合 |
| 礼貌邮件 | 友好、客气 | 请求、感谢 |
| 简洁邮件 | 简短、直接 | 内部沟通、紧急事务 |
| 友好邮件 | 轻松、亲切 | 同事间、熟悉的人 |
 
## 邮件结构模板
 

收件人:[邮箱地址] 主题:[简洁明确的主题]

尊敬的[称呼],

[正文第一段:开头问候,说明写信目的]

[正文第二段:详细说明核心内容]

[正文第三段:说明需要的行动或期待]

此致 敬礼

[你的名字/职位] [日期]


## 输出示例

**用户请求**:帮我写一封请假邮件,内容是明天请假一天,因为感冒了

**你的输出**:

收件人:manager@company.com 主题:请假申请 - 2026年4月25日

尊敬的主管,

您好!

因身体不适(感冒),我计划于4月25日请假一天进行处理。

请假期间,工作已安排妥当,紧急事务可联系同事小李协助处理。

恳请批准。

此致 敬礼

张三 2026年4月24日


## 注意事项

1. 根据收件人和场景选择合适的语气
2. 主题要简洁明确,让对方一眼看懂邮件目的
3. 正文要分段落,不要写成一大坨
4. 重要信息要突出显示
5. 结尾要礼貌

第六部分:常见错误和避坑指南

6.1 frontmatter常见错误

错误一:缩进不对

# ❌ 错误:缩进不一致
---
name: code-reviewer
  description: xxx
version: 1.0.0
---
 
# ✅ 正确:统一使用空格缩进
---
name: code-reviewer
description: xxx
version: 1.0.0
---

错误二:字段名拼写错误

# ❌ 错误:descriptioin拼错了
descriptioin: xxx
 
# ✅ 正确
description: xxx

错误三:列表格式错误

# ❌ 错误:列表项没有用-开头
trigger:
  "代码审查"
  "检查代码"
 
# ✅ 正确:每个列表项前面要加-
trigger:
  - "代码审查"
  - "检查代码"

6.2 instructions常见错误

错误一:指令太模糊

# ❌ 不好:说了等于没说
instructions: |
  请帮助用户处理代码问题。
 
# ✅ 好:具体明确
instructions: |
  当用户发送代码时,你应该:
  1. 识别代码语言
  2. 检查语法错误
  3. 给出改进建议

错误二:指令互相矛盾

# ❌ 不好:前后矛盾
instructions: |
  你应该简洁回答。
  同时,你应该详细解释每个细节。
 
# ✅ 好:逻辑一致
instructions: |
  你应该简洁回答,但重要概念要详细解释。

错误三:遗漏边界情况

# ❌ 不好:没考虑异常输入
instructions: |
  用户发送代码你就审查。
 
# ✅ 好:考虑边界情况
instructions: |
  当用户发送代码时:
  - 如果是代码 → 审查
  - 如果不是代码 → 提示用户发送代码
  - 如果代码过长 → 提示用户分段发送

6.3 文件结构常见错误

错误一:frontmatter没闭合

# ❌ 错误:只有开始标记
---
name: xxx
description: xxx
 
# ✅ 正确:首尾都有---
---
name: xxx
description: xxx
---

错误二:多余的内容在frontmatter里

# ❌ 不好:把正文内容放进了frontmatter
---
name: xxx
instructions: |
  你是一个助手...
---
 
# ✅ 正确:instructions应该放在---
---
 
你是一个助手...

第七部分:快速参考卡片

7.1 frontmatter字段速查

字段是否必须说明示例
nameSkill名称name: code-reviewer
description一句话描述description: 代码审查
version版本号version: 1.0.0
author作者author: 张三
category分类category: 开发工具
tags标签tags: 代码审查
trigger触发词trigger: "代码审查"
requires依赖requires: [SKILL.xxx]
tools工具tools: [file_reader]

7.2 instructions结构模板

instructions: |
  ## 角色定义
  你是一个[角色描述]。
 
  ## 核心职责
  当[触发条件]时,你应该[执行步骤]。
 
  ## 输出格式
  你的输出必须遵循以下格式:
  [格式模板]
 
  ## 边界情况
  - 如果[情况A] → [处理方式]
  - 如果[情况B] → [处理方式]

7.3 文件名命名规范

SKILL.<功能描述>[-<变体>].md

示例:
SKILL.code-reviewer.md           # 基础版本
SKILL.code-reviewer-v2.md        # 带版本
SKILL.code-reviewer-fast.md      # 快版本变体
SKILL.code-reviewer-detailed.md  # 详细版本变体

总结:写好SKILL.md的关键点

  1. frontmatter要规范:字段名不能拼错,缩进要一致
  2. 描述要简洁:一句话说清楚功能,不要啰嗦
  3. instructions要具体:明确的步骤比模糊的描述有效得多
  4. 格式要清晰:用列表、标题、分段落,让结构一目了然
  5. 考虑边界情况:什么情况该怎么处理,要提前想好
  6. 多看示例:照着好的示例写,事半功倍

下一步

搞定了语法,下一步你应该:

  1. 照着上面的示例,自己写一个简单的Skill试试
  2. Skills编写规范,学习怎么写出高质量的Skill
  3. Skills设计模式,了解如何组织多个Skill

相关文档


本文档详细介绍了SKILL.md的完整语法规范,配有丰富的示例和避坑指南,适合零基础小白学习。