关于 skill-creator
为 Agent 和开发者提供创建模块化 Skill 的指南,涵盖结构、精简指令设计、配套资源、渐进式披露、命名及创建流程。
主要功能
- 01Skill 结构与元数据规范
- 02精简指令设计
- 03脚本、参考资料与素材
- 04渐进式披露模式
- 05命名与创建流程
适用场景
- 01规划可复用的 Agent Skill
- 02为 Skill 整理参考资料和脚本
- 03检查 Skill 的上下文使用效率
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ volcengine/ openviking --skill skill-creator安装后在 Claude Code 中输入/skill-creator确认已加载。
详细介绍
技能创建器
本技能为创建高效技能提供指导。
关于技能
技能是模块化、自包含的软件包,通过提供专业知识、工作流和工具来扩展 Agent 的能力。可以将它们视为针对特定领域或任务的“入门指南”——它们将 Agent 从通用 Agent 转变为具备程序性知识的专业 Agent,而这些知识是任何模型都无法完全拥有的。
技能提供什么
- 专业工作流 - 针对特定领域多步骤流程
- 工具集成 - 用于处理特定文件格式或 API 的说明
- 领域专业知识 - 公司特定知识、模式、业务逻辑
- 捆绑资源 - 用于复杂和重复任务的脚本、参考资料和资产
核心原则
简洁是关键
上下文窗口是一种公共资源。技能与 Agent 需要的其他所有内容共享上下文窗口:系统提示词、对话历史、其他技能的元数据以及实际用户请求。
默认假设:Agent 已经非常聪明。 只添加 Agent 尚不具备的上下文。对每条信息提出质疑:“Agent 真的需要这个解释吗?”以及“这一段是否值得其 token 成本?”
优先使用简洁示例而非冗长解释。
设置适当的自由度
将具体程度与任务的脆弱性和可变性相匹配:
高自由度(基于文本的说明):当多种方法都有效、决策取决于上下文,或启发式方法指导做法时使用。
中等自由度(伪代码或带参数的脚本):当存在首选模式、某些变化可接受,或配置会影响行为时使用。
低自由度(特定脚本、少量参数):当操作脆弱且易出错、一致性至关重要,或必须遵循特定顺序时使用。
可以将 Agent 想象为在探索一条路径:带有悬崖的狭窄桥梁需要特定的护栏(低自由度),而开阔的田野允许许多路线(高自由度)。
技能的解剖结构
每个技能都由必需的 SKILL.md 文件和可选的捆绑资源组成:
skill-name/
├── SKILL.md (required)
│ ├── YAML frontmatter metadata (required)
│ │ ├── name: (required)
│ │ └── description: (required)
│ └── Markdown instructions (required)
└── Bundled Resources (optional)
├── scripts/ - Executable code (Python/Bash/etc.)
├── references/ - Documentation intended to be loaded into context as needed
└── assets/ - Files used in output (templates, icons, fonts, etc.)
SKILL.md(必需)
每个 SKILL.md 都由以下部分组成:
- Frontmatter(YAML):包含
name和description字段。这些是 Agent 用来确定技能何时被使用的唯一字段,因此清晰且全面地描述技能是什么以及何时应使用它非常重要。 - 正文(Markdown):使用技能的说明和指导。仅在技能触发之后(如果有)才加载。
捆绑资源(可选)
脚本(scripts/)
用于需要确定性可靠性或会被反复重写的任务的可执行代码(Python/Bash 等)。
- 何时包含:当同一代码被反复重写或需要确定性可靠性时
- 示例:用于 PDF 旋转任务的
scripts/rotate_pdf.py - 优势:token 高效、确定性、可无需加载到上下文中即可执行
- 注意:Agent 仍可能需要读取脚本以进行修补或针对环境的调整
参考 (references/)
按需加载到上下文中、用于指导 Agent 处理过程和思考的文档与参考资料。
- 何时包含:当 Agent 在工作过程中需要参考某些文档时
- 示例:
references/finance.md用于财务 schema,references/mnda.md用于公司 NDA 模板,references/policies.md用于公司政策,references/api_docs.md用于 API 规范 - 使用场景:数据库 schema、API 文档、领域知识、公司政策、详细工作流指南
- 优势:让 SKILL.md 保持精简,仅在 Agent 判断需要时才加载
- 最佳实践:如果文件较大(>10k 词),在 SKILL.md 中包含 grep 搜索模式
- 避免重复:信息应只存在于 SKILL.md 或 references 文件中,而不是两者都有。除非信息确实对技能至关重要,否则优先放在 references 文件中——这样既能让 SKILL.md 保持精简,又能让信息可被发现,同时不会占用上下文窗口。SKILL.md 中只保留必要的流程说明和工作流指导;将详细参考资料、schema 和示例移到 references 文件中。
资源 (assets/)
不打算加载到上下文中,而是用于 Agent 所生成输出中的文件。
- 何时包含:当技能需要用于最终输出的文件时
- 示例:
assets/logo.png用于品牌资源,assets/slides.pptx用于 PowerPoint 模板,assets/frontend-template/用于 HTML/React 样板代码,assets/font.ttf用于字体 - 使用场景:模板、图片、图标、样板代码、字体、会被复制或修改的示例文档
- 优势:将输出资源与文档分离,使 Agent 无需将文件加载到上下文中即可使用
技能中不应包含的内容
技能只应包含直接支持其功能的必要文件。不要创建无关的文档或辅助文件,包括:
- README.md
- INSTALLATION_GUIDE.md
- QUICK_REFERENCE.md
- CHANGELOG.md
- 等等。
技能只应包含 AI Agent 完成手头工作所需的信息。它不应包含关于创建过程的辅助上下文、安装和测试流程、面向用户的文档等。创建额外的文档文件只会增加杂乱和困惑。
渐进式披露设计原则
技能使用三级加载系统来高效管理上下文:
- 元数据(名称 + 描述) - 始终在上下文中(约 100 词)
- SKILL.md 正文 - 当技能触发时(<5k 词)
- 捆绑资源 - 按 Agent 需要加载(不受限制,因为脚本可以在不读入上下文窗口的情况下执行)
渐进式披露模式
让 SKILL.md 正文只保留必要内容,并控制在 500 行以内,以尽量减少上下文膨胀。接近此限制时,将内容拆分到单独的文件中。将内容拆分到其他文件时,务必从 SKILL.md 中引用它们,并清楚描述何时读取它们,以确保技能的读者知道它们的存在以及何时使用它们。
关键原则: 当一个技能支持多种变体、框架或选项时,SKILL.md 中只保留核心工作流和选择指引。将变体特定的细节(模式、示例、配置)移到单独的参考文件中。
模式 1:带参考文件的高层指南
# PDF Processing
## Quick start
Extract text with pdfplumber:
[code example]
## Advanced features
- **Form filling**: See [FORMS.md](FORMS.md) for complete guide
- **API reference**: See [REFERENCE.md](REFERENCE.md) for all methods
- **Examples**: See [EXAMPLES.md](EXAMPLES.md) for common patterns
Agent 仅在需要时才加载 FORMS.md、REFERENCE.md 或 EXAMPLES.md。
模式 2:按领域组织
对于涉及多个领域的技能,按领域组织内容,以避免加载无关上下文:
bigquery-skill/
├── SKILL.md (overview and navigation)
└── reference/
├── finance.md (revenue, billing metrics)
├── sales.md (opportunities, pipeline)
├── product.md (API usage, features)
└── marketing.md (campaigns, attribution)
当用户询问销售指标时,Agent 只读取 sales.md。
同样,对于支持多个框架或变体的技能,按变体组织:
cloud-deploy/
├── SKILL.md (workflow + provider selection)
└── references/
├── aws.md (AWS deployment patterns)
├── gcp.md (GCP deployment patterns)
└── azure.md (Azure deployment patterns)
当用户选择 AWS 时,Agent 只读取 aws.md。
模式 3:条件性细节
展示基础内容,链接到进阶内容:
# DOCX Processing
## Creating documents
Use docx-js for new documents. See [DOCX-JS.md](DOCX-JS.md).
## Editing documents
For simple edits, modify the XML directly.
**For tracked changes**: See [REDLINING.md](REDLINING.md)
**For OOXML details**: See [OOXML.md](OOXML.md)
Agent 仅在用户需要这些功能时才读取 REDLINING.md 或 OOXML.md。
重要准则:
- 避免深层嵌套引用 - 引用与 SKILL.md 之间保持一层深度。所有参考文件都应直接从 SKILL.md 链接。
- 组织较长的参考文件 - 对于超过 100 行的文件,在顶部包含目录,以便 Agent 在预览时能看到完整范围。
技能创建流程
技能创建涉及以下步骤:
- 通过具体示例理解技能
- 规划可复用的技能内容(脚本、参考、资源)
- 初始化技能(运行 init_skill.py)
- 编辑技能(实现资源并编写 SKILL.md)
- 打包技能(运行 package_skill.py)
- 根据实际使用情况迭代
按顺序遵循这些步骤,仅在有明确理由表明不适用时才跳过。
技能命名
- 仅使用小写字母、数字和连字符;将用户提供的标题规范为连字符格式(例如 "Plan Mode" ->
plan-mode)。 - 生成名称时,生成不超过 64 个字符的名称(字母、数字、连字符)。
- 优先使用描述动作的简短动词开头短语。
- 当有助于提高清晰度或触发效果时,按工具添加命名空间(例如
gh-address-comments、linear-address-issue)。 - 技能文件夹的名称应与技能名称完全一致。
第 1 步:通过具体示例理解技能
仅当技能的用法模式已经清楚理解时,才跳过此步骤。即使在使用现有技能时,这一步仍然有价值。
要创建有效的技能,需要清楚理解技能将如何被使用的具体示例。这种理解可以来自用户直接提供的示例,也可以来自生成后经用户反馈验证的示例。
例如,在构建图像编辑器技能时,相关问题包括:
- "image-editor 技能应支持哪些功能?编辑、旋转,还是其他?"
- "你能给出一些这个技能如何被使用的示例吗?"
- "我可以想象用户会提出诸如 'Remove the red-eye from this image' 或 'Rotate this image' 这样的请求。你还能想到这个技能的其他使用方式吗?"
- "用户说什么话时应该触发这个技能?"
为避免让用户不堪重负,避免在单条消息中提出过多问题。从最重要的问题开始,并根据需要继续追问,以获得更好的效果。
当对技能应支持的功能有了清晰认识时,结束此步骤。
第 2 步:规划可复用技能内容
要将具体示例转化为有效的技能,请通过以下方式分析每个示例:
- 考虑如何从零开始执行该示例
- 确定在重复执行这些工作流时,哪些脚本、参考文档和资源会有所帮助
示例:在构建 pdf-editor 技能以处理诸如“帮我旋转这个 PDF”之类的查询时,分析表明:
- 旋转 PDF 每次都需要重新编写相同的代码
- 将一个
scripts/rotate_pdf.py脚本存储在技能中会有所帮助
示例:在设计 frontend-webapp-builder 技能以处理诸如“帮我构建一个 todo 应用”或“帮我构建一个用于追踪步数的仪表盘”之类的查询时,分析表明:
- 编写前端 Web 应用每次都需要相同的 HTML/React 样板代码
- 将一个包含样板 HTML/React 项目文件的
assets/hello-world/模板存储在技能中会有所帮助
示例:在构建 big-query 技能以处理诸如“今天有多少用户登录了?”之类的查询时,分析表明:
- 查询 BigQuery 每次都需要重新发现表结构和关系
- 将一个记录表结构的
references/schema.md文件存储在技能中会有所帮助
要确定技能的内容,请分析每个具体示例,列出要包含的可复用资源:脚本、参考文档和资源。
第 3 步:初始化技能
此时,是时候实际创建技能了。
仅当要开发的技能已经存在,且需要进行迭代或打包时,才跳过此步骤。在这种情况下,请继续下一步。
从零开始创建新技能时,务必运行 init_skill.py 脚本。该脚本会方便地生成一个新的模板技能目录,自动包含技能所需的一切,从而使技能创建过程更加高效和可靠。
用法:
scripts/init_skill.py <skill-name> --path <output-directory> [--resources scripts,references,assets] [--examples]
示例:
scripts/init_skill.py my-skill --path skills/public
scripts/init_skill.py my-skill --path skills/public --resources scripts,references
scripts/init_skill.py my-skill --path skills/public --resources scripts --examples
该脚本:
- 在指定路径创建技能目录
- 生成带有正确 frontmatter 和 TODO 占位符的 SKILL.md 模板
- 可选地根据
--resources创建资源目录 - 可选地在设置
--examples时添加示例文件
初始化后,根据需要自定义 SKILL.md 并添加资源。如果你使用了 --examples,请替换或删除占位文件。
第 4 步:编辑技能
在编辑(新生成的或现有的)技能时,请记住,该技能是为另一个 Agent 实例使用而创建的。请包含对 Agent 有益且非显而易见的信息。考虑哪些过程性知识、领域特定细节或可复用资源能帮助另一个 Agent 实例更有效地执行这些任务。
学习经过验证的设计模式
根据你的技能需求,参考这些有用的指南:
- 多步骤流程:关于顺序工作流和条件逻辑,请参见 references/workflows.md
- 特定输出格式或质量标准:关于模板和示例模式,请参见 references/output-patterns.md
这些文件包含有效技能设计的成熟最佳实践。
从可复用技能内容开始
要开始实现,请从上面确定的可复用资源开始:scripts/、references/ 和 assets/ 文件。请注意,此步骤可能需要用户输入。例如,在实现 brand-guidelines 技能时,用户可能需要提供要存储在 assets/ 中的品牌资源或模板,或要存储在 references/ 中的文档。
添加的脚本必须通过实际运行来测试,以确保没有 bug 且输出符合预期。如果有很多相似的脚本,只需测试一个有代表性的样本,以在确保它们都能正常工作的信心与完成时间之间取得平衡。
如果你使用了 --examples,请删除技能不需要的任何占位文件。只创建实际需要的资源目录。
更新 SKILL.md
编写指南: 始终使用祈使/不定式形式。
Frontmatter
编写包含 name 和 description 的 YAML frontmatter:
name:技能名称description:这是技能的主要触发机制,可帮助 Agent 理解何时使用该技能。- 同时包含该技能的功能以及使用它的具体触发条件/场景。
- 将所有“何时使用”的信息都写在这里——不要写在正文中。正文只有在触发后才会加载,因此正文中的“何时使用此技能”部分对 Agent 没有帮助。
docx技能的示例 description:“Comprehensive document creation, editing, and analysis with support for tracked changes, comments, formatting preservation, and text extraction. Use when the agent needs to work with professional documents (.docx files) for: (1) Creating new documents, (2) Modifying or editing content, (3) Working with tracked changes, (4) Adding comments, or any other document tasks”
不要在 YAML frontmatter 中包含任何其他字段。
正文
编写有关如何使用该技能及其捆绑资源的说明。
步骤 5:打包技能
技能开发完成后,必须将其打包为可分发的 .skill 文件,并与用户共享。打包过程会自动先验证技能,以确保其满足所有要求:
scripts/package_skill.py <path/to/skill-folder>
可选的输出目录指定:
scripts/package_skill.py <path/to/skill-folder> ./dist
打包脚本将:
-
验证技能,自动检查:
- YAML frontmatter 格式和必填字段
- 技能命名规范和目录结构
- description 的完整性和质量
- 文件组织和资源引用
-
如果验证通过,则打包技能,创建一个以技能命名的 .skill 文件(例如
my-skill.skill),其中包含所有文件,并保持适当的目录结构以便分发。.skill 文件是扩展名为 .skill 的 zip 文件。
如果验证失败,脚本将报告错误并退出,不创建包。修复所有验证错误,然后再次运行打包命令。
步骤 6:迭代
测试技能后,用户可能会要求改进。这通常发生在使用技能后不久,此时对技能的表现仍有清晰的印象。
迭代工作流:
- 在真实任务中使用该技能
- 留意遇到的困难或低效之处
- 确定应如何更新 SKILL.md 或捆绑资源
- 实施更改并再次测试