Skill Creator

⚠️ 性能提示: 此 Skill 包含完整的评估体系（Grader/Comparator/Analyzer），适合在创建重要 Skill 时使用。对于简单 Skill，可跳过评估环节。

Skill Creator

此 Skill 提供创建高质量 Skills 的完整工作流指导。

关于 Skills

Skills 是模块化、自包含的包，通过提供专业领域的知识、工作流程和工具来扩展 Claude 的能力。可以将它们视为特定领域或任务的"入职指南"——它们将 Claude 从通用代理转变为配备程序性知识的专业代理。

Skills 提供的价值

1. 专业工作流 - 多步骤的特定领域流程
2. 工具集成 - 处理特定文件格式或 API 的说明
3. 领域专业知识 - 公司特定的知识、模式、业务逻辑
4. 打包资源 - 复杂和重复性任务的脚本、参考文档和资源

核心原则

简洁为王

上下文窗口是公共资源。Skills 与 Claude 需要的所有其他内容共享上下文窗口：系统提示、对话历史、其他 Skills 的元数据以及实际的用户请求。

默认假设：Claude 已经非常聪明。 只添加 Claude 不具备的上下文。质疑每一段信息："Claude 真的需要这个解释吗？" 和 "这段话的 token 成本合理吗？"

用简洁的示例代替冗长的解释。

设置适当的自由度

根据任务的脆弱性和可变性设置具体的指导程度：

把 Claude 想象成探索路径：狭窄的悬崖桥需要具体的护栏（低自由度），而开阔的田野允许多条路线（高自由度）。

Skill 结构

每个 Skill 由一个必需的 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 确定何时使用 Skill 的唯一依据，因此清晰描述 Skill 的功能和触发场景非常重要。
• Body (Markdown): 使用 Skill 的说明和指导。只在 Skill 被激活后加载。

打包资源

Scripts (scripts/)

用于需要确定性可靠性或反复重写的任务的可执行代码。

• 何时包含: 当相同的代码被反复重写或需要确定性可靠性时
• 示例: PDF 旋转任务的 scripts/rotate_pdf.py
• 优势: Token 高效、确定性、可执行而不加载到上下文

References (references/)

用于按需加载到上下文中以指导 Claude 过程和思维的文档和参考资料。

• 何时包含: 当 Claude 应该参考的文档时
• 示例: 财务模式的 references/finance.md、API 文档的 references/api_docs.md
• 最佳实践: 如果文件很大（>10k 字），在 SKILL.md 中包含 grep 搜索模式

Assets (assets/)

不打算加载到上下文中，而是用于 Claude 生成的输出中的文件。

• 何时包含: 当 Skill 需要用于最终输出的文件时
• 示例: 品牌资源的 assets/logo.png、模板的 assets/frontend-template/

What to Not Include in a Skill

A skill should only contain essential files that directly support its functionality. Do NOT create extraneous documentation or auxiliary files, including:

• README.md
• INSTALLATION_GUIDE.md
• QUICK_REFERENCE.md
• CHANGELOG.md
• etc.

The skill should only contain the information needed for an AI agent to do the job at hand. It should not contain auxilary context about the process that went into creating it, setup and testing procedures, user-facing documentation, etc. Creating additional documentation files just adds clutter and confusion.

Progressive Disclosure Design Principle

Skills use a three-level loading system to manage context efficiently:

1. Metadata (name + description) - Always in context (~100 words)
2. SKILL.md body - When skill triggers (<5k words)
3. Bundled resources - As needed by Claude (Unlimited because scripts can be executed without reading into context window)

Progressive Disclosure Patterns

Keep SKILL.md body to the essentials and under 500 lines to minimize context bloat. Split content into separate files when approaching this limit. When splitting out content into other files, it is very important to reference them from SKILL.md and describe clearly when to read them, to ensure the reader of the skill knows they exist and when to use them.

Key principle: When a skill supports multiple variations, frameworks, or options, keep only the core workflow and selection guidance in SKILL.md. Move variant-specific details (patterns, examples, configuration) into separate reference files.

Pattern 1: High-level guide with references

# 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

Claude loads FORMS.md, REFERENCE.md, or EXAMPLES.md only when needed.

Pattern 2: Domain-specific organization

For Skills with multiple domains, organize content by domain to avoid loading irrelevant context:

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)

When a user asks about sales metrics, Claude only reads sales.md.

Similarly, for skills supporting multiple frameworks or variants, organize by variant:

cloud-deploy/
├── SKILL.md (workflow + provider selection)
└── references/
    ├── aws.md (AWS deployment patterns)
    ├── gcp.md (GCP deployment patterns)
    └── azure.md (Azure deployment patterns)

When the user chooses AWS, Claude only reads aws.md.

Pattern 3: Conditional details

Show basic content, link to advanced content:

# 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)

Claude reads REDLINING.md or OOXML.md only when the user needs those features.

Important guidelines:

• Avoid deeply nested references - Keep references one level deep from SKILL.md. All reference files should link directly from SKILL.md.
• Structure longer reference files - For files longer than 100 lines, include a table of contents at the top so Claude can see the full scope when previewing.

Skill Creation Process

Skill creation involves these steps:

1. Understand the skill with concrete examples
2. Plan reusable skill contents (scripts, references, assets)
3. Initialize the skill (run init_skill.py)
4. Edit the skill (implement resources and write SKILL.md)
5. Package the skill (run package_skill.py)
6. 迭代改进 - 根据真实使用反馈优化 Skill

Follow these steps in order, skipping only if there is a clear reason why they are not applicable.

Step 5: 评估与质量保证

创建 Skill 后，必须进行严格的质量评估。使用三 Agent 评估体系：

5.1 Grader（评分者）

职责: 严格评估 Skill 输出质量

评估维度:

• 准确性 (1-5): 输出是否准确回答问题？
• 完整性 (1-5): 是否覆盖所有必要步骤？
• 可执行性 (1-5): 指令是否清晰可执行？
• 边界处理 (1-5): 错误和异常是否处理得当？

判定标准:

• 平均分 ≥ 4.0/5 → 通过
• 任何维度 < 3 → 不通过
• 其他情况 → 迭代后重评

5.2 Comparator（盲比较者）

职责: 不知道来源的情况下对比 Skill vs 非 Skill 输出

比较维度:

• 任务完成度 (40%): 哪个更好地解决问题？
• 代码质量 (25%): 哪个更规范易维护？
• 清晰度 (20%): 哪个解释更清晰？
• 边界处理 (15%): 哪个考虑更多边界情况？

判定标准:

• Skill 输出明显更好 ≥ 60% → 评估通过
• 其他情况 → 问题诊断后调整

5.3 Analyzer（分析者）

职责: 聚合评估数据，分析原因并提出改进建议

分析内容:

• 总体统计（通过率、平均得分）
• 维度分析（最高/最低/平均分）
• 成功模式（可复制的特征）
• 失败原因（根本问题）
• 改进建议（按 P0/P1/P2 优先级排序）

判定标准:

• P0 建议 < 1 → 可发布
• P0 建议 ≥ 1 → 必须修复
• P1 建议 < 3 → 可发布
• P1 建议 ≥ 3 → 迭代后发布

评估流程图

新 Skill → 收集测试用例 → Grader 评估
    ↓
  {通过?} 
  ├─ 是 → Comparator 盲测
  └─ 否 → 返回改进 → 重新收集用例
    ↓
  {A 更好?}
  ├─ 是 → Analyzer 分析
  └─ 否 → 问题诊断 → 调整 Skill
    ↓
  {改进建议 < 3?}
  ├─ 是 → 发布
  └─ 否 → 迭代改进

快速评估指南

简单 Skill（< 3KB）:

1. 准备 5 个测试用例
2. Grader 评估（1 轮）
3. Comparator 盲测（1 轮）
4. 如通过，发布

复杂 Skill（> 10KB 或多功能）:

1. 准备 20 个测试用例（10 happy path + 10 edge cases）
2. Grader 评估（3 轮，每轮优化）
3. Comparator 盲测（2 轮）
4. Analyzer 完整分析
5. 根据建议迭代
6. 最终发布评审

详细评估文档: 参考 AGENTS.md 获取完整的 Agent 定义、评估模板和最佳实践。

Step 6: 迭代改进

根据评估反馈持续优化：

1. 收集真实反馈

   • 用户使用数据（使用次数、成功率）
   • 评估结果（Grader/Comparator/Analyzer）
   • 错误报告和边界情况

2. 优先级排序

   • P0: 影响核心功能的 bug
   • P1: 重要的体验问题
   • P2: 优化建议

3. 小步迭代

   • 每次迭代聚焦 1-2 个问题
   • 避免一次性大改
   • 每次修改后重新评估

4. 发布节奏

   • 简单修复: 随时发布
   • 功能调整: 每周发布
   • 大改: 每月发布

Step 1: Understanding the Skill with Concrete Examples

Skip this step only when the skill's usage patterns are already clearly understood. It remains valuable even when working with an existing skill.

To create an effective skill, clearly understand concrete examples of how the skill will be used. This understanding can come from either direct user examples or generated examples that are validated with user feedback.

For example, when building an image-editor skill, relevant questions include:

• "What functionality should the image-editor skill support? Editing, rotating, anything else?"
• "Can you give some examples of how this skill would be used?"
• "I can imagine users asking for things like 'Remove the red-eye from this image' or 'Rotate this image'. Are there other ways you imagine this skill being used?"
• "What would a user say that should trigger this skill?"

To avoid overwhelming users, avoid asking too many questions in a single message. Start with the most important questions and follow up as needed for better effectiveness.

Conclude this step when there is a clear sense of the functionality the skill should support.

Step 2: Planning the Reusable Skill Contents

To turn concrete examples into an effective skill, analyze each example by:

1. Considering how to execute on the example from scratch
2. Identifying what scripts, references, and assets would be helpful when executing these workflows repeatedly

Example: When building a pdf-editor skill to handle queries like "Help me rotate this PDF," the analysis shows:

1. Rotating a PDF requires re-writing the same code each time
2. A scripts/rotate_pdf.py script would be helpful to store in the skill

Example: When designing a frontend-webapp-builder skill for queries like "Build me a todo app" or "Build me a dashboard to track my steps," the analysis shows:

1. Writing a frontend webapp requires the same boilerplate HTML/React each time
2. An assets/hello-world/ template containing the boilerplate HTML/React project files would be helpful to store in the skill

Example: When building a big-query skill to handle queries like "How many users have logged in today?" the analysis shows:

1. Querying BigQuery requires re-discovering the table schemas and relationships each time
2. A references/schema.md file documenting the table schemas would be helpful to store in the skill

To establish the skill's contents, analyze each concrete example to create a list of the reusable resources to include: scripts, references, and assets.