Skill Maker 🔨
Create powerful, reusable skills with structured reasoning.
The Skill Maker Framework
CODEBLOCK0
Decision Tree: What Are We Building?
CODEBLOCK1
Step 1: Interpret
The Core Questions
| Question | Your Answer |
|---|
| What does this skill DO? | [Capability] |
| Who asks for it? |
[User triggers] |
|
What's the DOMAIN? | [Topic area] |
|
How COMPLEX is it? | Simple/Medium/Complex |
Self-Check: Interpretation
- - [ ] Can I describe the skill in one sentence?
- [ ] Do I know what phrases would trigger it?
- [ ] Is this truly a new capability?
Step 2: Design
Complexity Decision
CODEBLOCK2
Directory Structure
CODEBLOCK3
Writing Triggers
Users typically say:
- - "I need to [action]"
- "How do I [task]?"
- "Help me with [domain]"
- "Can you [capability]?"
Formula for description:
"[What it does]. Use when: (1) [situation 1], (2) [situation 2], (3) [situation 3]."
Example:
"Fetch weather data from wttr.in. Use when: (1) User asks about weather, (2) User wants forecast, (3) User asks temperature in [city]."
Self-Check: Design
- - [ ] Name follows convention (lowercase, hyphens)?
- [ ] Description has clear triggers?
- [ ] I know which resources to include?
Step 3: Forge
SKILL.md Template
Copy this template for your skill:
CODEBLOCK4
Content Patterns
| Pattern | Use For |
|---|
| Numbered steps | Sequential workflows |
| Decision tree |
Branching logic |
| Tables | Quick reference |
| Code blocks | Examples |
| Error sections | Troubleshooting |
Progressive Disclosure
CODEBLOCK5
Self-Check: Forge
- - [ ] Frontmatter complete (name + description)?
- [ ] Body has reasoning framework?
- [ ] Self-check prompts included?
- [ ] Resources properly structured?
Step 4: Test
Trigger Testing
Read your description and ask:
CODEBLOCK6
Self-Check: Test
- - [ ] Does description match likely user phrases?
- [ ] Is the skill findable via search?
- [ ] Are there clear steps to follow?
- [ ] Does it include error handling?
Step 5: Polish
Refinement Loop
CODEBLOCK7
Common Fixes
| Problem | Solution |
|---|
| Won't trigger | Add more "Use when:" triggers |
| Too long |
Move details to references/ |
| Confusing | Add example scenarios |
| Missing cases | Add troubleshooting section |
Self-Check: Polish
- - [ ] Tested on real task?
- [ ] User feedback incorporated?
- [ ] Ready for regular use?
Versioning Guide
When to Bump Version
| Change Type | Version Bump | Example |
|---|
| Bug fix, no new features | 1.0.0 → 1.0.1 | v1.0.1 |
| New feature, backward compatible |
1.0.1 → 1.1.0 | v1.1.0 |
| Breaking changes | 1.1.0 → 2.0.0 | v2.0.0 |
Changelog Format
CODEBLOCK8
Self-Check: Versioning
- - [ ] Did I increment the version correctly?
- [ ] Is changelog updated?
- [ ] Is this a breaking change?
Metadata Best Practices
Frontmatter Fields
CODEBLOCK9
Emoji Selection
| Category | Emoji | Examples |
|---|
| Research | 🔬 | deep-research-pro, paper-compare |
| Coding |
💻 | code |
| Creation | 🔨 | skill-forge |
| Utility | ⚡ | surge |
| Weather | 🌤️ | weather |
| Discovery | 🔍 | find-skills |
| Media | 🎞️ | video-frames |
| Files | 📄 | pdf |
Category Tags
| Category | When to Use |
|---|
| research | Research, analysis, comparisons |
| coding |
Code-related tasks |
| utility | Tools, downloads, file operations |
| creation | Building new things |
| communication | Messaging, notifications |
| media | Video, audio, images |
Requirements Metadata
CODEBLOCK10
Self-Check: Metadata
- - [ ] Is frontmatter complete?
- [ ] Is emoji appropriate for category?
- [ ] Are requirements listed?
- [ ] Is version correct?
Why This Works
The Skill Logic Pattern
Based on research (SkillsBench 2026):
- 1. Reasoning framework → Agent knows HOW to think, not just WHAT to do
- Decision trees → Agent can handle different scenarios
- Self-checks → Agent validates its work
- Progressive disclosure → Context-efficient
The Goldilocks Principle
"2-3 focused modules beat exhaustive documentation"
Keep it:
- - ✅ Complete enough to be useful
- ✅ Concise enough to fit in context
- ✅ Structured enough to guide reasoning
Example: Forging a Weather Skill
Step 1: Interpret
- - What: Fetch weather from wttr.in
- Triggers: "weather in [city]", "temperature", "forecast"
- Domain: Weather data
Step 2: Design
- - Complexity: Simple (just API calls)
- Structure: SKILL.md only
- Name: INLINECODE0
Step 3: Forge
CODEBLOCK11
Step 4-5: Test & Polish
- - Add more triggers ("sunny?", "rain?")
- Add error handling (wrong city, no network)
- Add presentation templates
Why This Works
Based on research (SkillsBench 2026), skills with reasoning frameworks perform better because they give agents a thinking structure, not just steps to follow.
Made with Skill Maker 🔨
技能锻造者 🔨
使用结构化推理创建强大、可复用的技能。
技能锻造框架
┌─────────────────────────────────────────────────────────────┐
│ 技能锻造流程 │
├─────────────────────────────────────────────────────────────┤
│ 1. 解读 → 该技能需要什么能力? │
│ 2. 设计 → 结构、资源、触发条件 │
│ 3. 锻造 → 编写 SKILL.md,创建资源 │
│ 4. 测试 → 验证触发条件,检查质量 │
│ 5. 打磨 → 基于测试结果进行优化 │
└─────────────────────────────────────────────────────────────┘
决策树:我们在构建什么?
意图
│
├── 全新技能 ──→ 从步骤 1 开始
│
├── 替换现有技能 ──→
│ └── 先阅读旧技能,然后改进
│
└── 克隆并修改 ──→
└── 复制、重命名、自定义
步骤 1:解读
核心问题
| 问题 | 你的答案 |
|---|
| 该技能做什么? | [能力描述] |
| 谁会触发它? |
[用户触发条件] |
|
领域是什么? | [主题领域] |
|
复杂度如何? | 简单/中等/复杂 |
自查:解读
- - [ ] 我能用一句话描述该技能吗?
- [ ] 我知道哪些短语会触发它吗?
- [ ] 这真的是一个新能力吗?
步骤 2:设计
复杂度决策
复杂度等级
│
├── 简单 ──→ 仅 SKILL.md
│ └── 一个能力,清晰步骤
│
├── 中等 ──→ SKILL.md + references/
│ └── 需要文档作为参考
│
└── 复杂 ──→ SKILL.md + scripts/ + references/
└── 需要可执行代码
目录结构
skill-name/
├── SKILL.md # 必需:名称、描述、正文
├── scripts/ # 可选:可执行代码
├── references/ # 可选:详细文档
└── assets/ # 可选:模板、文件
编写触发条件
用户通常会说:
- - 我需要 [操作]
- 如何 [任务]?
- 帮我处理 [领域]
- 你能 [能力] 吗?
描述公式:
[功能描述]。使用场景:(1) [场景 1],(2) [场景 2],(3) [场景 3]。
示例:
从 wttr.in 获取天气数据。使用场景:(1) 用户询问天气,(2) 用户想要天气预报,(3) 用户询问 [城市] 温度。
自查:设计
- - [ ] 名称遵循规范(小写、连字符)?
- [ ] 描述包含清晰的触发条件?
- [ ] 我知道需要包含哪些资源?
步骤 3:锻造
SKILL.md 模板
为你的技能复制此模板:
yaml
name: my-skill
description: [功能描述]。使用场景:(1) [触发条件 1],(2) [触发条件 2],(3) [触发条件 3]。
我的技能
技能激活条件
当用户想要 [能力] 时触发此技能。
[领域] 框架
[做什么] |
| 3 | [做什么] |
工作流程
步骤 1:[名称]
[做什么及原因]
步骤 2:[名称]
[做什么及原因]
决策点
- - 如果 [条件]:执行 [A]
- 如果 [条件]:执行 [B]
常见场景
场景 1:[案例]
[做什么]
场景 2:[案例]
[做什么]
故障排除
问题:[错误]
快速参考
[命令/步骤] |
内容模式
分支逻辑 |
| 表格 | 快速参考 |
| 代码块 | 示例 |
| 错误部分 | 故障排除 |
渐进式信息展示
在 SKILL.MD 中(< 500 行):
├── 核心工作流(必须了解)
├── 关键示例(最常见)
└── 快速参考
在 REFERENCES/ 中:
├── 详细文档
├── API 规范
├── 边界情况
└── 扩展示例
自查:锻造
- - [ ] 前置元数据完整(名称 + 描述)?
- [ ] 正文包含推理框架?
- [ ] 包含自查提示?
- [ ] 资源结构合理?
步骤 4:测试
触发条件测试
阅读你的描述并提问:
描述:[你的描述]
这能否匹配用户说:
- - [触发短语 1]? → 是/否
- [触发短语 2]? → 是/否
- [触发短语 3]? → 是/否
自查:测试
- - [ ] 描述是否匹配用户可能使用的短语?
- [ ] 技能是否可通过搜索找到?
- [ ] 是否有清晰的步骤可遵循?
- [ ] 是否包含错误处理?
步骤 5:打磨
优化循环
使用技能 → 发现问题 → 修复 → 再次使用
↑ │
└────────────────────────────────────┘
常见修复
| 问题 | 解决方案 |
|---|
| 无法触发 | 添加更多使用场景:触发条件 |
| 过长 |
将细节移至 references/ |
| 令人困惑 | 添加示例场景 |
| 缺少情况 | 添加故障排除部分 |
自查:打磨
- - [ ] 已在真实任务上测试?
- [ ] 已纳入用户反馈?
- [ ] 可投入日常使用?
版本管理指南
何时升级版本
| 变更类型 | 版本升级 | 示例 |
|---|
| 错误修复,无新功能 | 1.0.0 → 1.0.1 | v1.0.1 |
| 新功能,向后兼容 |
1.0.1 → 1.1.0 | v1.1.0 |
| 破坏性变更 | 1.1.0 → 2.0.0 | v2.0.0 |
变更日志格式
markdown
版本 1.1.0
新增
变更
修复
自查:版本管理
- - [ ] 版本号是否正确递增?
- [ ] 变更日志是否已更新?
- [ ] 这是否是破坏性变更?
元数据最佳实践
前置元数据字段
yaml
name: my-skill
description: [功能描述]。使用场景:(1) [触发条件 1],(2) [触发条件 2]。
version: 1.0.0
changelog: [变更简要摘要]
metadata:
clawdbot:
emoji: 🔨 # 技能的表情符号
category: creation # 分类(research/coding/utility 等)
requires:
bins: [curl] # 必需的系统二进制文件
python: [requests] # 可选的 Python 包
表情符号选择
| 分类 | 表情符号 | 示例 |
|---|
| 研究 | 🔬 | deep-research-pro, paper-compare |
| 编码 |
💻 | code |
| 创建 | 🔨 | skill-forge |
| 工具 | ⚡ | surge |
| 天气 | 🌤️ | weather |
| 发现 | 🔍 | find-skills |
| 媒体 | 🎞️ | video-frames |
| 文件 | 📄 | pdf |
分类标签
| 分类 | 使用时机 |
|---|
| research | 研究、分析、比较 |
| coding |
代码相关任务 |
| utility | 工具、下载、文件操作 |
| creation | 构建新事物 |
| communication | 消息、通知 |
| media | 视频、音频、图片 |
依赖元数据
y