再学 AI
第 42 课 / write-a-skill
历史对照阅读 → 对照 → 问答 → 场景

历史对照:一份技能如何打包

这份历史指南讲需求、主文件、附件、脚本和审阅,适合第一次理解技能文件夹的组成。

历史文件,不在当前目录

本课使用下方注明的历史提交原文,帮助理解旧文章和旧提示词。请勿据此认定当前版本仍能直接调用该名称。

还不清楚 Skill、Agent、安装和调用?先读 从零开始的6节入门课

在关系图中查看 write-a-skill 与其他技能的关联 →

先把必要的概念讲清楚

这份历史指南提供技能文件的起步结构。学习时把它理解为组织重复工作的方法,而不是一份只要填模板就一定高效的通用规范。

下面是老师补充的入门说明;原作者的要求保留在中英对照正文中。所有例子均为帮助理解而构造的教学情境。

frontmatter|Markdown 文件头元数据

文档最前面两条 --- 之间的键值信息,如 name、description。正文讲怎样做事,文件头帮助宿主识别名称、用途和调用方式。保留字段名称是为了维持技术含义,不是要求你熟悉英文;具体支持哪些字段取决于客户端。

context pointer|上下文资料指引

告诉 Agent 在什么条件下去读哪份材料的短指引。例如“新增或修改数据写入时,先读权限规则文档”。它同时承担地址与触发条件两项作用。只有“见文档”太模糊,可能找不到或不知道何时需要;一股脑放入所有内容又会占用上下文。

CLI|命令行界面

通过输入文字命令操作程序,例如运行测试或检查 Git 状态。它与点按钮一样是操作入口,只是参数更容易记录、重复执行。读命令时先分清程序名、子命令、选项和目标路径;看懂命令不等于已执行它。

acceptance criteria|验收条件

明确规定结果满足什么才算完成,应尽量可观察、可检验。例如“收藏后刷新页面仍可见,重复点击只保留一条”。“体验很好”“代码完善”没有明确边界,难以判断。验收条件关注结果,不是把实现步骤换个标题列出来。

读原文,理解每一步为什么这样做

左右内容按小节对应;窄屏先中文、后英文。两种语言均完整展示,对应讲解紧接在小节之后。译文传达原文要求;老师讲解补充概念、原因、例子与适用边界。

译注

原文在起草步骤中提到超过 500 行增加参考文件,在后面的拆分规则和清单中又使用 100 行门槛。译文保留两种说法,实际编写时需自行选定一致标准。

中文译文English · 英文原文
中文译文
name: write-a-skill
description: "创建具有正确结构、渐进披露和配套资源的新 Agent skill。"
disable-model-invocation: true
English · 英文原文
name: write-a-skill
description: Create a new agent skill with proper structure, progressive disclosure, and bundled resources.
disable-model-invocation: true
中文译文

编写新的技能

English · 英文原文

Writing Skills

中文译文

编写过程

  1. 了解需求。 与用户确认:技能覆盖什么任务或领域;需要处理哪些具体场景;只需要操作说明,还是需要可执行脚本;有没有参考资料要附带。
  2. 起草技能。 创建包含简明操作说明的 SKILL.md。本段建议内容超过 500 行时增加参考文件;需要固定、可重复的处理操作时,增加工具脚本。
  3. 与用户审阅。 展示草稿,询问是否覆盖实际用途,有没有缺漏或不清楚之处,以及哪些部分应增加或减少细节。
English · 英文原文

Process

  1. Gather requirements - ask user about:

    • What task/domain does the skill cover?
    • What specific use cases should it handle?
    • Does it need executable scripts or just instructions?
    • Any reference materials to include?
  2. Draft the skill - create:

    • SKILL.md with concise instructions
    • Additional reference files if content exceeds 500 lines
    • Utility scripts if deterministic operations needed
  3. Review with user - present draft and ask:

    • Does this cover your use cases?
    • Anything missing or unclear?
    • Should any section be more/less detailed?
老师讲解 · 对应上方原文 · 含教学举例

先找重复问题,再决定是否需要技能

需求访谈应确定任务范围、典型用例、是否需要脚本和参考资料。例如“把每次学习记录转成可回顾笔记”可能有重复流程;“帮我改一句话”不一定值得新建技能。

简洁指令负责让 Agent 执行,脚本负责确定性操作,参考文件保存不常用细节。这些是按职责分配,不是越多目录越专业。

原文前面说超过 500 行加参考,后面却用 100 行门槛。译文保留矛盾,教师建议把可读性、分支和维护成本作为判断依据,不把两个数字同时当硬规则。

中文译文

技能文件夹的结构

一个 skill-name/ 文件夹必须有主说明 SKILL.md。需要时,可添加详细文档 REFERENCE.md、示例 EXAMPLES.md,以及 scripts/helper.js 等工具脚本。

English · 英文原文

Skill Structure

skill-name/
├── SKILL.md           # Main instructions (required)
├── REFERENCE.md       # Detailed docs (if needed)
├── EXAMPLES.md        # Usage examples (if needed)
└── scripts/           # Utility scripts (if needed)
    └── helper.js
中文译文

SKILL.md 模板

---
name: skill-name
description: 简要说明能力。Use when [具体触发场景]。
---

# 技能名称

## 快速开始

[一个最小但可用的示例]

## 工作流程

[逐步操作说明;复杂任务可配检查清单]

## 高级功能

[链接到独立资料,例如 [REFERENCE.md](REFERENCE.md)]
English · 英文原文

SKILL.md Template

---
name: skill-name
description: Brief description of capability. Use when [specific triggers].
---

# Skill Name

## Quick start

[Minimal working example]

## Workflows

[Step-by-step processes with checklists for complex tasks]

## Advanced features

[Link to separate files: See [REFERENCE.md](REFERENCE.md)]
中文译文

description 应怎样写

按本文描述,Agent 决定加载哪个技能时,首先看到的是 description。它与其他已安装技能的描述一起进入系统提示,帮助 Agent 根据用户任务选择。

目标是让 Agent 知道两件事:这个技能提供什么能力;什么时候或为什么需要调用,例如具体关键词、情境和文件类型。

格式要求:最多 1024 个字符;使用第三人称;第一句说明做什么;第二句用 Use when 说明何时使用。

好的示例:

提取 PDF 的文字和表格、填写表单、合并文档。处理 PDF,或者用户提到 PDF、表单、文档提取时使用。

不好的示例:

帮助处理文档。

后者无法让 Agent 区分它与其他文档技能。

English · 英文原文

Description Requirements

The description is the only thing your agent sees when deciding which skill to load. It's surfaced in the system prompt alongside all other installed skills. Your agent reads these descriptions and picks the relevant skill based on the user's request.

Goal: Give your agent just enough info to know:

  1. What capability this skill provides
  2. When/why to trigger it (specific keywords, contexts, file types)

Format:

  • Max 1024 chars
  • Write in third person
  • First sentence: what it does
  • Second sentence: "Use when [specific triggers]"

Good example:

Extract text and tables from PDF files, fill forms, merge documents. Use when working with PDF files or when user mentions PDFs, forms, or document extraction.

Bad example:

Helps with documents.

The bad example gives your agent no way to distinguish this from other document skills.

老师讲解 · 对应上方原文 · 含教学举例

文件头中的描述,帮助选择而非完成工作

name 是技能标识,description 说明能力与触发情形。原文称它是选择时唯一能见到的东西,严格说这依赖宿主实现,应理解为作者强调描述对发现的重要性。

“提取 PDF 的文本和表格、填表或合并”能与文章改写区分;“帮助文档”无法区分。格式与长度限制也应以实际客户端规范为准。

一个好描述只能帮助选中正确技能,真正行为仍取决于正文、可用工具和输入资料。不能把发现成功当执行成功。

description 像目录说明,正文才是完整操作方法

假设你写“帮助学习”,Agent 很难判断它是翻译、出题、复习,还是查资料。更具体的描述可以说“为软件工程初学者逐段翻译英文技能,并提供对应例子;用户要求精读 SKILL.md 时使用”。

description 负责让客户端或模型发现适用性;真正加载后,正文再规定输入、步骤、产物和完成条件。安装通常是让客户端能够发现这一文件夹,不是把知识训练进模型参数。

如果操作只是按理解生成解释,可能只有文档就够。如果每次都要检查 53 个文件是否齐全,固定脚本更适合承担重复校验。

原文前面写超过 500 行才增加参考文件,后面却要求主文件少于 100 行,存在不一致。这里保留差异供学习,不把它伪装成统一标准。实际编写应按当前平台规范和任务需要确定结构,不能为了达到字数目标删掉关键步骤。

中文译文

什么时候添加脚本

如果操作具有固定规则,例如校验或格式化;相同代码会被反复生成;或者错误需要明确处理,就考虑附带脚本。

与每次临时生成代码相比,复用脚本可以减少 token 消耗,提高一致性。

English · 英文原文

When to Add Scripts

Add utility scripts when:

  • Operation is deterministic (validation, formatting)
  • Same code would be generated repeatedly
  • Errors need explicit handling

Scripts save tokens and improve reliability vs generated code.

老师讲解 · 对应上方原文 · 含教学举例

稳定规则交给脚本,变化判断留给模型

验证文件名、格式化数据等确定性操作,脚本可以重复使用,不必每次由模型重新生成。涉及取舍、解释或未知背景时,则仍需要模型和人共同判断。

例如脚本可检查 53 个译文文件是否都存在,却不能仅靠文件数量判断每篇是否教得清楚。机械检查和内容评审负责不同问题。

引用保持浅层,是降低找资料成本的经验。若一个 skill 必须连续追五级链接才知道第一步,可能需要重新组织,而不是继续加说明。

中文译文

什么时候拆成多个文件

本段建议以下情况拆分:SKILL.md 超过 100 行;内容包含明显不同的领域,例如金融与销售的数据结构;或者某些高级内容很少需要。

English · 英文原文

When to Split Files

Split into separate files when:

  • SKILL.md exceeds 100 lines
  • Content has distinct domains (finance vs sales schemas)
  • Advanced features are rarely needed
中文译文

完成后的检查

  • [ ] description 包含明确触发场景。
  • [ ] SKILL.md 少于 100 行。
  • [ ] 不包含容易过时的信息。
  • [ ] 术语一致。
  • [ ] 有具体示例。
  • [ ] 引用保持一层深度。
English · 英文原文

Review Checklist

After drafting, verify:

  • [ ] Description includes triggers ("Use when...")
  • [ ] SKILL.md under 100 lines
  • [ ] No time-sensitive info
  • [ ] Consistent terminology
  • [ ] Concrete examples included
  • [ ] References one level deep
老师讲解 · 对应上方原文 · 含教学举例

清单通过,不是技能已验证有效

描述有触发词、术语一致、有例子,都是起步检查。更关键的是让它处理一个真实代表性任务,观察是否按预期执行、是否遇到缺少工具、是否在完成标准前草率停止。

例如写了“不要漏项”,运行时仍只检查前三课,就需要更可观察的覆盖要求。增加同一句警告通常不如改清流程和证据要求。

历史清单不能替代当前宿主安装规则。创建了 Markdown,也不等于已经被工具识别或安装。

原作者:Matt Pocock · 中文翻译为非官方译本

来源:skills/productivity/write-a-skill/SKILL.md ↗

固定版本:221ffca96736afefdc08ca7cf0b3965e9ea83f41

先作答,再看参考思路

Q1 · 理解

用自己的话说明:它解决什么问题,完成后会留下什么?

请各用一句话回答。若它只做规划或解释,不要把“已开发”“已部署”写成产物。

Q2 · 判断

同一文件给出 100 行与 500 行两个阈值,你应怎样处理?

我已思考,查看参考思路

记录矛盾,回到目的和当前宿主要求判断。不能选择自己喜欢的数字后声称作者原文只有一个标准。

Q3 · 追问

原文中哪条要求在你的环境下可能不成立?

说出具体一句及其前提,例如工具不可用、资料缺失、已有项目约定冲突,或它只是作者偏好。把你的答案带回课堂,我们据此继续讨论。

课堂回传格式:第 42 课 / 我的理解 / Q2 回答 / 仍不理解的原句。这里是阅读教材;实时问答在我们的对话中进行。

把方法放进一个具体情境

教学案例:制作“引用核验”技能,来源支持判断需要语义理解,链接格式和字段完整性则适合程序检查。二者分工清楚比纯长提示词更可靠。

边界与容易误读的地方

本课是阅读历史原文,不会在你的环境自动安装技能。旧字段限制和行数建议不能当作所有客户端现行规范。

讨论后再实践:先判断上述情境是否适用,再选择真实任务。现在无需安装、运行命令或修改现有项目。

关联阅读