skill-creator-pro

技能创建专家版

创建生产级技能，扩展 Claude 的能力。

此技能的工作方式

User: "Create a skill for X"
       ↓
Claude Code uses this meta-skill as guidance
       ↓
Follow Domain Discovery → Ask user clarifying questions → Create skill
       ↓
Generated skill with embedded domain expertise

此技能提供创建技能的指导和结构。Claude Code：

1. 使用此技能的框架来探索领域知识
2. 向用户询问其特定需求的澄清信息
3. 根据领域需求决定如何构建生成的技能

此技能的功能

• 指导从头开始创建新技能
• 帮助将现有技能提升到生产级质量
• 提供适用于 5 种技能类型（构建器、指南、自动化、分析器、验证器）的模式
• 确保技能编码流程知识和领域专业知识

此技能不负责的事项

• 处理技能创建后的版本管理和更新
• 创建针对特定需求的技能（始终创建可复用的智能能力）
• 将技能部署到生产环境（但交付前必须进行本地测试）

---

领域探索框架

核心原则：用户希望技能具备领域专业知识，但用户本身未必是领域专家。

阶段 1：自动探索（无需用户输入）

在询问任何问题前，主动研究该领域：

探索内容	方法	示例：“Kafka 集成”
核心概念	官方文档、Context7	生产者、消费者、主题、分区
标准/合规要求	搜索“[领域] standards”	Kafka 安全性、精确一次语义
最佳实践	搜索“[领域] best practices 2025”	分区策略、消费者组
反模式	搜索“[领域] common mistakes”	分区过多、未进行监控
安全性	搜索“[领域] security”	SASL、SSL、ACL、加密
生态系统	搜索“[领域] ecosystem tools”	Confluent、Schema Registry、Connect

来源优先级：官方文档 → 库文档（Context7）→ GitHub → 社区 → WebSearch

阶段 2：知识充分性检查

在向用户询问任何问题前，先在内部确认：

- [ ] Core concepts understood?
- [ ] Best practices identified?
- [ ] Anti-patterns known?
- [ ] Security considerations covered?
- [ ] Official sources found?

If ANY gap → Research more (don't ask user for domain knowledge)
Only if CANNOT discover (proprietary/internal) → Ask user

阶段 3：用户需求（而非领域知识）

只询问用户的具体情境：

询问	不要询问
“您的用例是什么？”	“Kafka 是什么？”
“您的技术栈是什么？”	“有哪些选项？”
“有现成的资源吗？”	“它是如何运作的？”
“有具体限制吗？”	“最佳实践是什么？”

技能包含领域专业知识。用户提供需求。

---

必要的澄清信息

询问有关技能元数据和用户需求的问题（而非领域知识）：

技能元数据

1. 技能类型——“技能属于哪种类型？”

类型	用途	示例
构建器（Builder）	创建产物	小部件、代码、文档
指南（Guide）	提供说明	操作指南、教程
自动化（Automation）	执行工作流	文件处理、部署
分析器（Analyzer）	提取见解	代码审查、数据分析
验证器（Validator）	保障质量	合规性检查、评分

2. 领域——“属于哪个领域或涉及哪种技术？”

用户需求（领域探索之后）

3. 用例——“您的具体用例是什么？”

• 不是“它能做什么”，而是“您需要什么”

4. 技术栈——“您的环境是什么？”

• 语言、框架、现有基础设施

5. 现有资源——“是否有需要纳入的脚本、模板或配置？”

6. 限制条件——“是否有具体要求或限制？”

• 针对用户情境的性能、安全和合规要求

注意

• 问题 1-2：立即询问
• 领域探索：了解领域后自动开展研究
• 问题 3-6：完成探索后，结合领域知识进行询问
• 提问节奏：避免在一条消息中提出过多问题。先询问最重要的问题，再根据需要跟进。

---

核心原则

可复用的智能能力，而非针对特定需求

技能必须能够处理变化情况，而非单一需求：

❌ Bad: "Create bar chart with sales data using Recharts"
✅ Good: "Create visualizations - adaptable to data shape, chart type, library"

❌ Bad: "Deploy to AWS EKS with Helm"
✅ Good: "Deploy applications - adaptable to platform, orchestration, environment"

识别领域中哪些内容会变化，哪些内容是恒定的。参见 references/reusability-patterns.md。

简洁为要

上下文窗口是公共资源（每次激活技能约需 1,500+ 个 token）。请审视每一部分：

• “Claude 真的需要这段解释吗？”
• “这段文字值得占用这些 token 吗？”

优先使用简洁的示例，而非冗长的解释。

适当的自由度

根据任务的脆弱程度匹配具体程度：

自由度	使用场景	示例
高	有多种有效方法	“选择你喜欢的风格”
中	存在首选模式	带参数的伪代码
低	操作脆弱	精确脚本，参数尽量少

渐进式披露

三级加载系统：

1. 元数据（约 100 个 token）——始终位于上下文中（description ≤1024 个字符）
2. SKILL.md 正文（<500 行）——技能触发时加载
3. 参考资料（不限）——Claude 按需加载

---

技能剖析

生成的技能是嵌入了知识的零样本领域专家。

skill-name/
├── SKILL.md (required)
│   ├── YAML frontmatter (name, description, allowed-tools?, model?)
│   └── Procedural knowledge (workflows, steps, decision trees)
└── Bundled Resources
    ├── references/   - Domain expertise (structure based on domain needs)
    ├── scripts/      - Executable code (tested, reliable)
    └── assets/       - Templates, boilerplate, images

SKILL.md 要求

组件	要求
行数	<500 行（提取到 references/）
Frontmatter	完整规范见 references/skill-patterns.md
name	小写字母、数字、连字符；≤64 个字符；与目录名一致
description	[内容] + [时机]；≤1024 个字符；使用第三人称风格
描述风格	“This skill should be used when...” （不要写 “Use when...”）
形式	使用祈使句（“执行 X”，而非 “你应该执行 X”）
范围	说明它会做什么，以及不会做什么

references/ 中应包含的内容

嵌入探索过程中收集的领域知识：

收集的知识	在技能中的用途
库/API 文档	支持正确实现
最佳实践	指导质量决策
代码示例	提供参考模式
反模式	避免常见错误
领域特定细节	支持边缘情况

根据领域需求组织 references/。

大型文件：如果 references/ 超过 10k 个单词，请在 SKILL.md 中加入 grep 搜索模式，便于高效查找。

何时生成 scripts/

当领域需要确定性、可执行的流程时，生成脚本：

领域需求	示例脚本
设置/安装	安装依赖、初始化项目
处理	转换数据、处理文件
验证	检查合规性、验证输出
部署	部署服务、配置基础设施

判断标准：如果流程复杂、容易出错或需要精确重复执行 → 创建脚本。否则 → 在 SKILL.md 或 references/ 中说明。

何时生成 assets/

当领域需要精确模板或样板代码时，生成资源：

领域需求	示例资源
起始模板	HTML 样板、组件脚手架
配置文件	配置模板、模式定义
代码样板	基类、入门代码

不要包含的内容

• README.md（SKILL.md 就是 readme）
• CHANGELOG.md
• LICENSE（继承自仓库）
• 重复信息

生成的技能在运行时会做什么

User invokes skill → Gather context from:
  1. Codebase (if existing project)
  2. Conversation (user's requirements)
  3. Own references/ (embedded domain expertise)
  4. User-specific guidelines
→ Ensure all information gathered → Implement ZERO-SHOT

生成的技能应包含的内容

每个生成的技能都应包含：

## Before Implementation

Gather context to ensure successful implementation:

| Source | Gather |
|--------|--------|
| **Codebase** | Existing structure, patterns, conventions to integrate with |
| **Conversation** | User's specific requirements, constraints, preferences |
| **Skill References** | Domain patterns from `references/` (library docs, best practices, examples) |
| **User Guidelines** | Project-specific conventions, team standards |

Ensure all required context is gathered before implementing.
Only ask user for THEIR specific requirements (domain expertise is in this skill).

---

按类型创建

确定技能类型后，遵循相应类型的模式：

类型	关键章节	参考
构建器	澄清 → 输出规范 → 标准 → 检查清单	skill-patterns.md#builder
指南	工作流 → 示例 → 官方文档	skill-patterns.md#guide
自动化	脚本 → 依赖 → 错误处理	skill-patterns.md#automation
分析器	范围 → 标准 → 输出格式	skill-patterns.md#analyzer
验证器	标准 → 评分 → 阈值 → 修正措施	skill-patterns.md#validator

---

技能创建流程

Metadata → Discovery → Requirements → Analyze → Embed → Structure → Implement → Validate

详细步骤请参阅 references/creation-workflow.md。

快速步骤

1. 元数据：询问技能类型和领域（问题 1-2）
2. 探索：自动研究领域（上文阶段 1-2）
3. 需求：询问用户的具体需求（问题 3-6）
4. 分析：识别流程性（HOW）和领域（WHAT）知识
5. 嵌入：将收集到的领域专业知识放入 references/
6. 构建结构：初始化技能目录
7. 实现：按照类型模式编写 SKILL.md 和资源
8. 验证：运行 scripts/package_skill.py 并测试

SKILL.md 模板

---
name: skill-name                    # lowercase, hyphens, ≤64 chars
description: |                      # ≤1024 chars
  [What] Capability statement.
  [When] Use when users ask to <triggers>.
allowed-tools: Read, Grep, Glob     # optional: restrict tools
---

完整的 frontmatter 规范和正文模式见 references/skill-patterns.md。

---

输出检查清单

交付技能前，请确认：

领域探索已完成

• 已发现并理解核心概念
• 已从可信来源识别最佳实践
• 已记录反模式
• 已涵盖安全注意事项
• 已链接官方文档
• 未询问用户领域知识

Frontmatter

• name：小写，使用连字符，≤64 个字符，与目录名称一致
• description：[内容]+[适用时机]，≤1024 个字符，触发条件明确
• allowed-tools：如需限制访问，则设置

结构

• SKILL.md <500 行
• 渐进式披露（详细内容放在 references/ 中）

设计原则（见 references/design-principles.md）

• 模块化（一个技能 = 一项职责）
• 清晰（明确胜过巧妙）
• 简洁（复杂度最低）
• 透明（可检查、可调试）

知识覆盖

• 流程性（HOW）：工作流、决策树、错误处理
• 领域（WHAT）：概念、最佳实践、反模式

零样本实现（在生成的技能中）

• 包含“实现前”部分
• 收集运行时上下文（代码库、对话、用户指南）
• 将领域专业知识嵌入 references/（按照领域需求组织）
• 仅询问用户自身的需求（不询问领域知识）

可复用性

• 能处理各种情况（不针对特定需求）
• 澄清问题用于收集可变要素（用户的上下文）
• 将常量编码（领域模式、最佳实践）

类型专属（见 references/skill-patterns.md）

• 构建器：澄清问题、输出规范、标准、检查清单
• 指南：工作流、示例、官方文档
• 自动化：脚本、依赖项、错误处理
• 分析器：范围、标准、输出格式
• 验证器：标准、评分、阈值、补救措施

实战测试（必需）

• 已测试部署：make test 或等效命令通过
• 已验证版本：工具版本为最新，未使用已弃用的 API
• 已测试真实场景：技能能够回答领域问题，而不只是部署工具
• 已执行资源：assets/ 中的每个文件都已实际运行
• 没有过度设计：使用原生工具（Helm、kubectl），而非 Python 封装

详细验证流程见 references/validation-checklist.md。

---

参考文件

文件	阅读时机
references/design-principles.md	将 Unix 哲学应用于技能设计（基础内容）
references/creation-workflow.md	详细的逐步创建流程
references/skill-patterns.md	Frontmatter 规范、类型专属模式、资源指南
references/reusability-patterns.md	流程性与领域知识、变化项与常量
references/quality-patterns.md	澄清问题、执行、检查清单
references/technical-patterns.md	错误处理、安全性、依赖项
references/workflows.md	顺序和条件工作流模式
references/output-patterns.md	模板和示例模式