Back to Details

skill-creator

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Skill Creator

Skill Creator

Interactive, guided skill creation following Anthropic's best practices.
遵循Anthropic最佳实践的交互式、引导式Skill创建流程。

Important

重要说明

  • NEVER generate a skill without first completing the Discovery phase
  • ALWAYS present the full understanding summary and get explicit user approval before writing any skill files
  • ALWAYS include test and validation steps in every created skill where applicable
  • Quality is more important than speed -- take your time to do this thoroughly
  • 绝不在未完成探索阶段的情况下生成Skill
  • 在编写任何Skill文件之前，始终要呈现完整的需求理解摘要并获得用户的明确批准
  • 始终在每个创建的Skill中包含适用的测试和验证步骤
  • 质量比速度更重要——请花时间仔细完成整个流程

Workflow Overview

工作流概述

Skill creation follows four phases in strict order:
  1. Discovery -- Ask questions, clarify requirements, gather examples
  2. Approval -- Present understanding summary, get user sign-off
  3. Build -- Initialize, write SKILL.md, README.md, and resources, run validation
  4. Test & Deliver -- Generate test suite, run validation, package
Do NOT skip or merge phases. Complete each phase before proceeding.
Skill创建严格按照以下四个阶段依次进行：
  1. 探索阶段 —— 提出问题、明确需求、收集示例
  2. 审批阶段 —— 呈现需求理解摘要、获得用户确认
  3. 构建阶段 —— 初始化、编写SKILL.md、README.md及相关资源、执行验证
  4. 测试与交付阶段 —— 生成测试套件、执行验证、打包
请勿跳过或合并任何阶段。完成当前阶段后再进入下一阶段。

Phase 1: Discovery

阶段1：探索阶段

Goal: Understand exactly what the user needs before writing anything.
目标：在开始编写任何内容之前，准确理解用户的需求。

Step 1.1: Identify the Core Purpose

步骤1.1：明确核心目标

Ask the user:
  • "What task or workflow should this skill handle?"
  • "Can you give 2-3 concrete examples of how you would use this skill?"
If the user's answer is vague or only covers one scenario, ask follow-up:
  • "What would a user say to trigger this skill?"
  • "Are there related tasks this skill should also handle, or should those be separate?"
向用户询问：
  • “这个Skill需要处理什么任务或工作流？”
  • “你能否给出2-3个具体的使用场景示例？”
如果用户的回答模糊或仅涵盖一种场景，继续追问：
  • “用户会说什么来触发这个Skill？”
  • “是否有相关的任务也需要由这个Skill处理，还是应该单独创建Skill？”

Step 1.2: Clarify Technical Requirements

步骤1.2：明确技术要求

Based on the user's answers, determine:
  • Category: Document & Asset Creation, Workflow Automation, or MCP Enhancement
  • Approach: Problem-first (user describes outcomes) or Tool-first (user has tools, needs guidance)
  • Tools needed: Built-in Claude tools, MCP servers, or external scripts
  • Dependencies: Required packages, APIs, services
Ask about anything unclear:
  • "Does this skill need to interact with any external services or MCP servers?"
  • "Are there specific output formats or quality standards required?"
  • "Should this skill work with specific file types?"
根据用户的回答，确定：
  • 分类：文档与资产创建、工作流自动化、MCP增强
  • 方法：问题优先（用户描述预期结果）或工具优先（用户已有工具，需要指导）
  • 所需工具：Claude内置工具、MCP服务器或外部脚本
  • 依赖项：所需的包、API、服务
对不明确的内容进行询问：
  • “这个Skill是否需要与任何外部服务或MCP服务器交互？”
  • “是否有特定的输出格式或质量标准要求？”
  • “这个Skill是否需要处理特定的文件类型？”

Step 1.3: Identify Edge Cases and Error Scenarios

步骤1.3：识别边缘情况和错误场景

Ask:
  • "What could go wrong during this workflow?"
  • "How should the skill handle errors (e.g., missing data, API failures)?"
  • "Are there tasks that look similar but should NOT trigger this skill?"
询问：
  • “在这个工作流中可能会出现什么问题？”
  • “Skill应该如何处理错误（例如：数据缺失、API调用失败）？”
  • “是否存在看起来相似但不应触发这个Skill的任务？”

Step 1.4: Gather Domain Knowledge

步骤1.4：收集领域知识

If the skill embeds specialized knowledge:
  • "Do you have any reference documentation, templates, or examples to include?"
  • "Are there company-specific conventions or standards to follow?"
如果Skill需要嵌入专业知识：
  • “你是否有可以参考的文档、模板或示例？”
  • “是否有特定的公司规范或标准需要遵循？”

Discovery Completion Gate

探索阶段完成标准

Do NOT proceed to Phase 2 until you can clearly answer ALL of these:
  • What does the skill do? (purpose)
  • When should it trigger? (2-3 trigger phrases)
  • When should it NOT trigger? (negative triggers)
  • What are the workflow steps? (sequence)
  • What tools/resources are needed? (dependencies)
  • What can go wrong? (error cases)
If any answer is unclear, ask the user before proceeding.
在进入阶段2之前，必须能够清晰回答以下所有问题：
  • Skill的功能是什么？（目标）
  • 何时触发？（2-3个触发短语）
  • 何时不应触发？（排除触发场景）
  • 工作流步骤有哪些？（顺序）
  • 需要哪些工具/资源？（依赖项）
  • 可能出现哪些错误？（错误场景）
如果有任何问题的答案不明确，请先询问用户再继续。

Phase 2: Approval

阶段2：审批阶段

Goal: Present a complete understanding summary and get explicit user approval.
目标：呈现完整的需求理解摘要并获得用户的明确批准。

Step 2.1: Present the Understanding Summary

步骤2.1：呈现需求理解摘要

Display the following structured summary to the user:
undefined
向用户展示以下结构化摘要：
undefined

Skill Summary for Approval

待审批的Skill摘要

Name: [kebab-case-name] Category: [Document & Asset Creation / Workflow Automation / MCP Enhancement] Approach: [Problem-first / Tool-first]
名称： [kebab-case格式名称] 分类： [文档与资产创建 / 工作流自动化 / MCP增强] 方法： [问题优先 / 工具优先]

What It Does

功能描述

[1-2 sentence description]
[1-2句话描述]

When It Triggers (description field)

触发条件（描述字段）

[Draft description including WHAT + WHEN + trigger phrases]
[包含功能、触发时机和触发短语的草稿描述]

When It Should NOT Trigger

不应触发的场景

[Negative triggers / out-of-scope tasks]
[排除触发场景 / 超出范围的任务]

Workflow Steps

工作流步骤

  1. [Step 1]
  2. [Step 2]
  3. [Step N]
  1. [步骤1]
  2. [步骤2]
  3. [步骤N]

Error Handling

错误处理

  • [Error scenario 1] → [How to handle]
  • [Error scenario 2] → [How to handle]
  • [错误场景1] → [处理方式]
  • [错误场景2] → [处理方式]

Resources to Include

包含的资源

  • scripts/: [list or "none"]
  • references/: [list or "none"]
  • assets/: [list or "none"]
  • scripts/: [列表或“无”]
  • references/: [列表或“无”]
  • assets/: [列表或“无”]

Test Cases

测试用例

Should trigger:
  • "[example phrase 1]"
  • "[example phrase 2]"
  • "[example phrase 3]"
Should NOT trigger:
  • "[unrelated phrase 1]"
  • "[unrelated phrase 2]"
应触发：
  • “[示例短语1]”
  • “[示例短语2]”
  • “[示例短语3]”
不应触发：
  • “[无关短语1]”
  • “[无关短语2]”

Success Criteria

成功标准

  • [Criterion 1]
  • [Criterion 2]
undefined
  • [标准1]
  • [标准2]
undefined

Step 2.2: Get Explicit Approval

步骤2.2：获得明确批准

Ask the user:
  • "Does this summary accurately capture what you need? Please confirm or tell me what to change."
If the user requests changes, update the summary and re-present it. Do NOT proceed until the user explicitly approves.
向用户询问：
  • “这个摘要是否准确涵盖了你的需求？请确认或告诉我需要修改的内容。”
如果用户要求修改，更新摘要并重新呈现。在用户明确批准之前，请勿继续。

Phase 3: Build

阶段3：构建阶段

Goal: Create the skill folder, SKILL.md, and all resources.
目标：创建Skill文件夹、SKILL.md及所有相关资源。

Step 3.1: Initialize the Skill

步骤3.1：初始化Skill

Run the initialization script:
bash
python scripts/init_skill.py <skill-name> --path <output-directory>
Skip if updating an existing skill.
运行初始化脚本：
bash
python scripts/init_skill.py <skill-name> --path <output-directory>
如果是更新现有Skill，可跳过此步骤。

Step 3.2: Write the YAML Frontmatter

步骤3.2：编写YAML前置元数据

Use the approved summary to write the frontmatter:
yaml
---
name: [kebab-case-name]
version: 1.0.0
description: [approved description -- must include WHAT it does + WHEN to use it with trigger phrases. Under 1024 chars. No XML tags.]
---
Frontmatter rules:
  • name
    : kebab-case only, no spaces or capitals, must match folder name
  • version
    : semver format (MAJOR.MINOR.PATCH)
  • description
    : MUST include both WHAT the skill does and WHEN to use it
    • Structure: 
      [What it does] + [When to use it] + [Key capabilities]
    • Include specific trigger phrases users might say
    • Mention file types if relevant
    • Under 1024 characters
    • No XML angle brackets
  • Do not use "claude" or "anthropic" in the name (reserved)
Description quality check -- verify it is NOT:
  • Too vague (e.g., "Helps with projects")
  • Missing triggers (e.g., "Creates documentation systems")
  • Too technical without user triggers (e.g., "Implements entity model with relationships")
使用已批准的摘要编写前置元数据：
yaml
---
name: [kebab-case格式名称]
version: 1.0.0
description: [已批准的描述——必须包含功能和触发时机及触发短语。不超过1024字符。无XML标签。]
---
前置元数据规则：
  • name
    ：仅使用kebab-case格式，无空格或大写字母，必须与文件夹名称一致
  • version
    ：采用语义化版本格式（MAJOR.MINOR.PATCH）
  • description
    ：必须同时包含Skill的功能和触发时机
    • 结构：
      [功能描述] + [触发时机] + [核心能力]
    • 包含用户可能使用的具体触发短语
    • 如果相关，提及文件类型
    • 不超过1024字符
    • 无XML尖括号
  • 名称中不得使用“claude”或“anthropic”（为保留名称）
描述质量检查——确保描述不是：
  • 过于模糊（例如：“帮助处理项目”）
  • 缺少触发条件（例如：“创建文档系统”）
  • 过于技术化且无用户触发短语（例如：“实现带关系的实体模型”）

Step 3.3: Write the SKILL.md Body

步骤3.3：编写SKILL.md正文

Follow this structure (adapt sections as needed):
markdown
undefined
遵循以下结构（根据需要调整章节）：
markdown
undefined

[Skill Name]

[Skill名称]

Instructions

操作指南

Step 1: [First Major Step]

步骤1：[主要步骤1]

Clear, actionable explanation. [Include specific commands, parameters, expected output]
清晰、可执行的说明。 [包含具体命令、参数、预期输出]

Step 2: [Next Step]

步骤2：[下一步]

...
...

Examples

示例

Example 1: [Common Scenario]

示例1：[常见场景]

User says: "[trigger phrase]" Actions:
  1. [action]
  2. [action] Result: [expected outcome]
用户说：“[触发短语]” 操作：
  1. [操作1]
  2. [操作2] 结果：[预期输出]

Error Handling

错误处理

[Error Scenario]

[错误场景]

Cause: [why it happens] Solution: [specific fix steps]
原因： [发生原因] 解决方案： [具体修复步骤]

Validation

验证

[If applicable, include validation steps or checklist for the skill's output]

**Writing rules:**
- Be specific and actionable -- avoid vague instructions like "validate the data"
- Use imperative/infinitive form
- Include concrete commands with parameters
- Reference bundled resources clearly: `See references/api-guide.md for rate limiting`
- Keep SKILL.md under 500 lines; move details to `references/`
- Put critical instructions at the top
- Use bullet points and numbered lists over prose
- Include error handling for every workflow step that can fail
[如果适用，包含Skill输出的验证步骤或检查清单]

**编写规则：**
- 具体且可执行——避免模糊的指令如“验证数据”
- 使用祈使语气/不定式形式
- 包含带参数的具体命令
- 清晰引用捆绑资源：`请查看references/api-guide.md了解速率限制`
- 保持SKILL.md不超过500行；将详细内容移至`references/`目录
- 关键指令放在顶部
- 优先使用项目符号和编号列表而非散文
- 为每个可能失败的工作流步骤添加错误处理

Step 3.4: Create Supporting Resources

步骤3.4：创建支持资源

Scripts (
scripts/
):
  • Write executable code for deterministic/repetitive tasks
  • Test every script by actually running it
  • Include proper error handling and usage instructions
References (
references/
):
  • Move detailed documentation out of SKILL.md
  • Structure files with table of contents if over 100 lines
  • Keep references one level deep from SKILL.md
Assets (
assets/
):
  • Include templates, images, fonts used in output
  • Not intended to be loaded into context
Delete any example files from 
init_skill.py
that are not needed.
脚本（
scripts/
）：
  • 为确定性/重复性任务编写可执行代码
  • 实际运行每个脚本进行测试
  • 包含适当的错误处理和使用说明
参考文档（
references/
）：
  • 将详细文档从SKILL.md中移出
  • 如果超过100行，为文件添加目录
  • 参考文档与SKILL.md保持一级目录深度
资产（
assets/
）：
  • 包含输出中使用的模板、图片、字体
  • 不用于加载到上下文环境中
删除
init_skill.py
生成的所有不需要的示例文件。

Step 3.5: Add Test and Validation Section

步骤3.5：添加测试与验证章节

Every skill MUST include testing guidance. Add to the SKILL.md or as a separate 
references/testing.md
:
Triggering test suite:
Should trigger:
- "[obvious task phrase]"
- "[paraphrased request]"
- "[alternative wording]"

Should NOT trigger:
- "[unrelated topic]"
- "[similar but out-of-scope task]"
Functional test cases (where applicable):
Test: [test name]
Given: [preconditions]
When: [action]
Then:
  - [expected result 1]
  - [expected result 2]
  - [no errors]
每个Skill必须包含测试指南。添加到SKILL.md中或作为单独的
references/testing.md
文件：
触发测试套件：
应触发：
- “[明显任务短语]”
- “[改写后的请求]”
- “[替代表述]”

不应触发：
- “[无关主题]”
- “[相似但超出范围的任务]”
功能测试用例（如适用）：
测试：[测试名称]
给定：[前置条件]
当：[执行操作]
则：
  - [预期结果1]
  - [预期结果2]
  - 无错误

Step 3.6: Generate README.md

步骤3.6：生成README.md

Every skill MUST include a README.md for human-readable documentation. Use the following template:
markdown
undefined
每个Skill必须包含README.md作为人类可读的文档。使用以下模板：
markdown
undefined

[Skill Display Name]

[Skill显示名称]

[One-line description of what the skill does]
[一句话描述Skill的功能]

Highlights

核心亮点

  • [Key capability 1]
  • [Key capability 2]
  • [Key capability 3]
  • [Key capability 4]
  • [核心能力1]
  • [核心能力2]
  • [核心能力3]
  • [核心能力4]

When to Use

使用场景

Say this...Skill will...
"[trigger phrase 1]"[What happens]
"[trigger phrase 2]"[What happens]
"[trigger phrase 3]"[What happens]
说这样的话...Skill会...
“[触发短语1]”[执行操作]
“[触发短语2]”[执行操作]
“[触发短语3]”[执行操作]

How It Works

工作原理

 
mermaid graph TD     A["[First Step]"] --> B["[Second Step]"]     B --> C["[Third Step]"]     C --> D["[Final Step]"]     style A fill:#4CAF50,color:#fff     style D fill:#2196F3,color:#fff 
 
 
mermaid graph TD     A["[第一步]"] --> B["[第二步]"]     B --> C["[第三步]"]     C --> D["[最终步骤]"]     style A fill:#4CAF50,color:#fff     style D fill:#2196F3,color:#fff

Usage

使用方法

 
/[skill-name]
 
 
/[skill-name]

Output

输出结果

[Description of what the skill produces -- files, reports, etc.]

**README rules:**
- Title: Use the human-readable display name (e.g., "Code Optimizer", not "code-optimizer")
- Tagline: One sentence in blockquote format (> prefix)
- Highlights: 3-5 bullet points of key capabilities
- When to Use: Table with 3-4 trigger phrases mapping to actions
- How It Works: Mermaid `graph TD` diagram showing the main workflow steps. First node green (#4CAF50), last node blue (#2196F3)
- Usage: Code block with the slash command invocation
- Output: Brief description of what the skill produces
- Optional **Resources** section: Table with `| Path | Description |` columns if the skill has `scripts/`, `references/`, or `assets/` directories

---
[Skill生成内容的描述——文件、报告等]

**README规则：**
- 标题：使用人类可读的显示名称（例如：“代码优化器”，而非“code-optimizer”）
- 标语：使用块引用格式的一句话描述（> 前缀）
- 核心亮点：3-5个项目符号列出核心能力
- 使用场景：包含3-4个触发短语对应操作的表格
- 工作原理：使用Mermaid `graph TD` 图表展示主要工作流步骤。第一个节点为绿色（#4CAF50），最后一个节点为蓝色（#2196F3）
- 使用方法：包含斜杠命令调用的代码块
- 输出结果：简要描述Skill生成的内容
- 可选**资源**章节：如果Skill包含`scripts/`、`references/`或`assets/`目录，添加包含`| 路径 | 描述 |`列的表格

---

Phase 4: Test & Deliver

阶段4：测试与交付阶段

Goal: Validate the skill and deliver to the user.
目标：验证Skill并交付给用户。

Step 4.1: Run Structural Validation

步骤4.1：运行结构验证

Run the validation script:
bash
python scripts/quick_validate.py <path/to/skill-folder>
Fix any reported errors before proceeding.
运行验证脚本：
bash
python scripts/quick_validate.py <path/to/skill-folder>
在继续之前修复所有报告的错误。

Step 4.2: Manual Validation Checklist

步骤4.2：手动验证检查清单

Verify each item:
Structure:
  • Folder named in kebab-case
  • SKILL.md exists (exact spelling, case-sensitive)
  • YAML frontmatter has 
    ---
    delimiters
  • name
    is kebab-case, no spaces, no capitals
  • description
    includes WHAT and WHEN
  • No XML tags anywhere
  • README.md exists with correct template structure (title, tagline, highlights, when to use, how it works, usage, output)
Content:
  • Instructions are clear and actionable (no vague language)
  • Error handling included for failure scenarios
  • Examples provided with realistic user requests
  • References clearly linked from SKILL.md
  • No TODO placeholders remaining
  • SKILL.md under 500 lines
Testing:
  • Triggering test suite included (should/should-not trigger)
  • Functional test cases included where applicable
  • Scripts tested by running them
验证以下每一项：
结构：
  • 文件夹名称为kebab-case格式
  • 存在SKILL.md文件（拼写准确，区分大小写）
  • YAML前置元数据包含
    ---
    分隔符
  • name
    为kebab-case格式，无空格、无大写字母
  • description
    包含功能和触发时机
  • 无任何XML标签
  • 存在README.md且符合模板结构（标题、标语、核心亮点、使用场景、工作原理、使用方法、输出结果）
内容：
  • 操作指南清晰且可执行（无模糊语言）
  • 包含失败场景的错误处理
  • 提供带有真实用户请求的示例
  • SKILL.md中清晰链接到参考文档
  • 无剩余的TODO占位符
  • SKILL.md不超过500行
测试：
  • 包含触发测试套件（应触发/不应触发）
  • 如适用，包含功能测试用例
  • 脚本已通过实际运行测试

Step 4.3: Package the Skill

步骤4.3：打包Skill

bash
python scripts/package_skill.py <path/to/skill-folder> [output-directory]
The packaging script validates automatically and creates a versioned 
.skill
file.
bash
python scripts/package_skill.py <path/to/skill-folder> [output-directory]
打包脚本会自动执行验证并创建带版本号的
.skill
文件。

Step 4.4: Present to User

步骤4.4：交付给用户

Deliver the completed skill with:
  1. The 
    .skill
    file location
  2. Summary of what was created (SKILL.md, README.md, and supporting files)
  3. The test suite for the user to run
  4. Installation instructions:
    • Claude.ai: Settings > Capabilities > Skills > Upload
    • Claude Code: Place in skills directory
  5. Iteration guidance: "After using the skill, bring back any edge cases or failures to improve it"
向用户交付完成的Skill，包含：
  1. .skill
    文件的位置
  2. 创建内容的摘要（SKILL.md、README.md及支持文件）
  3. 供用户运行的测试套件
  4. 安装说明：
    • Claude.ai：设置 > 能力 > Skills > 上传
    • Claude Code：放置到skills目录
  5. 迭代指导：“使用Skill后，如有任何边缘情况或失败场景，请反馈以进行改进”

Core Principles Reference

核心原则参考

Concise is Key

简洁为要

The context window is a shared resource. Only add context Claude doesn't already have. Challenge each piece of information: "Does Claude really need this?" Prefer concise examples over verbose explanations.
上下文窗口是共享资源。仅添加Claude尚不具备的上下文信息。对每一条信息进行审视：“Claude真的需要这个吗？” 优先选择简洁的示例而非冗长的解释。

Progressive Disclosure

渐进式披露

Skills use three loading levels:
  1. Metadata (name + description) -- always in context (~100 words)
  2. SKILL.md body -- loaded when skill triggers (keep under 5k words)
  3. Bundled resources -- loaded as needed by Claude
Keep SKILL.md focused. Move detailed docs to 
references/
and link to them.
Skill采用三个加载层级：
  1. 元数据（名称+描述）——始终在上下文中（约100词）
  2. SKILL.md正文——Skill触发时加载（保持在5000词以内）
  3. 捆绑资源——Claude根据需要加载
保持SKILL.md的聚焦。将详细文档移至
references/
目录并进行链接。

Degrees of Freedom

自由度等级

Match specificity to the task:
  • High freedom (text instructions): Multiple valid approaches, context-dependent
  • Medium freedom (pseudocode/parameterized scripts): Preferred pattern exists, some variation OK
  • Low freedom (specific scripts): Fragile operations, consistency critical
根据任务匹配具体程度：
  • 高自由度（文本指令）：多种有效方法，依赖上下文
  • 中自由度（伪代码/参数化脚本）：存在首选模式，允许一定变化
  • 低自由度（特定脚本）：操作敏感，一致性至关重要

What NOT to Include

不应包含的内容

Do not create these files inside a skill:
  • CHANGELOG.md, INSTALLATION_GUIDE.md
  • Auxiliary context about the creation process
Exception: README.md IS required -- it provides human-readable documentation for browsing the skill catalog.
请勿在Skill中创建以下文件：
  • CHANGELOG.md、INSTALLATION_GUIDE.md
  • 关于创建过程的辅助上下文
例外： README.md是必需的——它为浏览Skill目录提供人类可读的文档。

Design Patterns

设计模式

For detailed patterns, consult these references:
  • Multi-step workflows: See 
    references/workflows.md
    for sequential and conditional patterns
  • Output quality: See 
    references/output-patterns.md
    for template and example patterns
如需详细模式，请参考以下文档：
  • 多步骤工作流：查看
    references/workflows.md
    了解顺序和条件模式
  • 输出质量：查看
    references/output-patterns.md
    了解模板和示例模式

Updating Existing Skills

更新现有Skill

When asked to update an existing skill:
  1. Read the current skill -- Understand what exists before changing anything
  2. Run Discovery -- Ask what needs to change and why
  3. Present changes for Approval -- Show a diff-style summary of proposed changes
  4. Apply changes -- Edit files, update version (PATCH for fixes, MINOR for features, MAJOR for breaking changes)
  5. Re-validate -- Run validation script and checklist
  6. Re-package -- Create new versioned 
    .skill
    file
当用户要求更新现有Skill时：
  1. 阅读当前Skill——在进行任何更改之前，先理解现有内容
  2. 执行探索阶段——询问需要更改的内容及原因
  3. 呈现待审批的更改——以差异风格的摘要展示拟议的更改
  4. 应用更改——编辑文件、更新版本（修复问题用PATCH版本，新增功能用MINOR版本，破坏性更改用MAJOR版本）
  5. 重新验证——运行验证脚本并检查清单
  6. 重新打包——创建新的带版本号的
    .skill
    文件