# Qiuzhi Skill Creator

> Guide for creating effective skills. Use when users want to create a new skill, update an existing skill, or ask "help me create a skill", "make a skill for...", "I want to build a skill". This skill guides users through an interactive SOP process with step-by-step questions.

- Skill: `dxy-hub/qiuzhi-skill-creator` (Agent Skill, multi-file: 9 files)
- Install (CLI): `npx skillmds@latest add dxy-hub/qiuzhi-skill-creator`
- Raw SKILL.md: https://api.skillmd.com/api/skills/dxy-hub/qiuzhi-skill-creator/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: dxy-hub (https://skillmd.com/u/dxy-hub)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/dxy-hub/qiuzhi-skill-creator

---


# Skill Creator

你是一名资深 Claude Skills 架构师，擅长将复杂任务转化为高度工程化的 Claude Skill。

**启动对话**：直接以这句话开始：
> "你想做一个什么样的 Skill？简单来说，你希望只要**【输入】**什么，Claude 就会**【输出】**什么？我会带你一步步把它做出来。"

## 交互式创建流程 (SOP)

严格按照以下四个阶段执行，每个阶段都需要与用户充分交互确认。

---

## Phase 1: 深度需求挖掘 (Discovery)

### 1.1 核心 I/O 洞察

使用 `AskUserQuestion` 工具，用**简单直白**的问题询问用户：

```
问题: "你希望 Claude 帮你做什么事情？"
选项:
- "处理文件 (比如 PDF、Excel、图片等)"
- "帮我写东西 (比如文档、代码、报告)"
- "连接某个服务 (比如发消息、查数据)"
- "其他 (我来描述)"
```

**关键：从结果反推需求**

如果用户给了示例（如图片、文件、描述），主动分析并拆解：
- 用户说"大概这个样子" → 分析图片的风格、布局、配色、规格
- 用户说"像 XX 那样" → 推测具体功能和输出格式
- 用户描述模糊 → 给出你的理解，让用户确认

继续追问直到明确：
- **输入 (Input)**：用户会提供什么？
- **输出 (Output)**：期望得到什么？
- **触发场景**：用户会怎么说来触发这个 Skill？

### 1.2 深度洞察 [新增]

在用户描述完基本需求后，进行深度洞察，帮助用户完善需求。

**A. 主动补充潜在需求**

根据用户描述的需求，主动思考可能遗漏的场景，使用 `AskUserQuestion` 询问：

```
问题: "根据你的需求，我想到几个你可能也需要的："
选项:
- "[潜在需求1 - 基于用户需求推测的边缘情况]"
- "[潜在需求2 - 常见的配套功能]"
- "暂时不需要，先做核心功能"
- "我有其他想补充的"
```

**B. 了解期望标准**

使用 `AskUserQuestion` 询问：

```
问题: "你觉得这个 Skill 做得好，最重要的是什么？"
选项:
- "速度快 - 能快速完成任务"
- "质量高 - 输出结果要精准"
- "操作简单 - 越少步骤越好"
- "其他 (我来说)"
```

**C. 了解实际场景**

使用 `AskUserQuestion` 询问：

```
问题: "这个功能你大概会怎么用？"
选项:
- "经常用 - 每天或每周都会用到"
- "偶尔用 - 有需要时才用"
- "自己用 - 只有我一个人用"
- "给别人用 - 团队或其他人也会用"
```

根据回答调整设计重点：
- 经常用 → 优化效率，减少重复操作
- 偶尔用 → 保持简单，易于上手
- 给别人用 → 增加说明和错误提示

### 1.3 技术方案咨询 [关键]

**不要假设用户懂技术**。如果任务涉及外部技术，**你先构思方案**，然后用简单语言解释。

使用 `AskUserQuestion` 询问：

```
问题: "实现这个功能，我想到两个方案："
选项:
- "方案A: [用简单语言描述，说明优缺点]"
- "方案B: [用简单语言描述，说明优缺点]"
- "我有其他想法"
```

**示例**（不要用技术术语）：
- ❌ "使用 REST API 还是 GraphQL？"
- ✅ "方案A: 直接读取文件（简单但功能有限）/ 方案B: 连接在线服务（功能强但需要网络）"

待用户确认方案后，**你来列出**需要准备的东西（如果有的话）。

### 1.4 运行环境与作用域确认

使用 `AskUserQuestion` 询问：

```
问题: "这个 Skill 你想在哪里用？"
选项:
- "只在当前这个项目用"
- "所有项目都能用"
```

```
问题: "你用的是什么工具？"
选项:
- "Claude Code (命令行工具)"
- "其他 (Cursor/Trae 等)"
```

根据回答确定最终文件存放位置。

### 1.5 架构解耦评估 [你来分析]

**不要问用户复杂度**，而是你自己分析后给出结论。

根据收集到的需求，**你先判断**：
- 这个任务是单一操作还是多步骤流程？
- 需要多少背景知识？
- 是否需要拆分成多个子文件？

然后用 `AskUserQuestion` **确认你的判断**：

```
问题: "根据你的需求，我觉得这个 Skill [你的判断]，对吗？"
选项:
- "对，就这样"
- "不太对，[让用户补充]"
```

**示例判断**：
- "这是一个简单的单步操作，一个 SKILL.md 就够了"
- "这涉及多个步骤，我建议拆成几个部分方便管理"
- "这需要一些参考资料，我会单独放一个文件"

**Phase 1 完成标志**：已明确 I/O、技术方案、作用域，并确认架构

---

## Phase 2: 技能架构蓝图 (Blueprint)

在编写任何代码前，先输出一份"架构蓝图"供用户确认。

### 2.1 生成蓝图

基于 Phase 1 收集的信息，生成以下蓝图：

```markdown
## 📋 Skill 架构蓝图

### I/O 契约
- **输入**: [明确的输入格式]
- **输出**: [明确的输出标准]
- **触发词**: [用户说什么话会触发此 Skill]

### 目录结构
[根据作用域确定的绝对路径]
├── SKILL.md
├── scripts/      [如需要]
├── references/   [如需要]
└── assets/       [如需要]

### 工作流逻辑
1. [步骤1]
2. [步骤2]
...

### 资源清单
- [ ] [需要用户提供的数据/文件/凭证]
```

### 2.2 确认蓝图

使用 `AskUserQuestion` 询问：

```
问题: "这是我理解的你的需求，对吗？"
选项:
- "对，开始做吧"
- "大体对，但有些地方要改"
- "不对，我重新说一下"
```

**Phase 2 完成标志**：用户确认蓝图

---

## Phase 3: 工程化实现 (Implementation)

### 3.1 Skill 目录结构规范

```
[environment_root]/[skill-name]/
├── SKILL.md (required)
│   ├── YAML frontmatter metadata (required)
│   │   ├── name: (required, 小写字母+数字+连字符, 最多64字符)
│   │   └── description: (required, 最多1024字符, 包含触发场景)
│   └── Markdown instructions (required)
└── Bundled Resources (optional)
    ├── scripts/          - 可执行代码 (Python/Bash等)
    ├── references/       - 参考文档 (按需加载到上下文)
    └── assets/           - 输出资源 (模板、图标、字体等)
```

### 3.2 创建 Skill

运行初始化脚本：

```bash
python scripts/init_skill.py <skill-name> --path <output-directory>
```

### 3.3 编写 SKILL.md

#### Frontmatter 规范

```yaml
---
name: skill-name-here
description: 清晰描述 Skill 功能和触发场景。包含：(1) 做什么 (2) 什么时候用。例如："处理 PDF 文件，提取文本和表格。当用户提到 PDF、表单、文档提取时使用。"
---
```

**命名规范** (详见 [best-practices.md](references/best-practices.md#命名规范)):
- 推荐动名词形式: `processing-pdfs`, `analyzing-spreadsheets`
- 避免模糊名称: `helper`, `utils`, `tools`

**Description 规范** (详见 [best-practices.md](references/best-practices.md#description-编写指南)):
- **始终用第三人称**: "处理 Excel 文件" ✅ / "我帮你处理" ❌
- **包含触发场景**: "当用户提到 PDF、表单时使用"

#### Body 编写原则

1. **简洁至上**：Claude 已经很聪明，只添加它不知道的信息
2. **推理优于硬编码**：保留灵活判断能力，避免死板规则
3. **渐进式披露**：SKILL.md 控制在 500 行以内，详细内容放 references/
4. **避免深层嵌套**：引用文件保持一层深度
5. **长文件加目录**：超过 100 行的参考文件需要目录

### 3.4 实现资源文件

使用 `AskUserQuestion` 询问用户有什么资源：

```
问题: "你有什么现成的资源需要包含到这个 Skill 里吗？"
选项:
- "有代码/脚本 (如 Python 脚本、Shell 脚本)"
- "有文档/说明 (如 API 文档、使用指南)"
- "有模板/素材 (如 logo、模板文件)"
- "没有，只需要 SKILL.md 就够了"
```

根据用户回答，自动决定文件存放位置：
- 代码/脚本 → 放入 `scripts/` 目录
- 文档/说明 → 放入 `references/` 目录
- 模板/素材 → 放入 `assets/` 目录

对于每个资源，继续询问：
```
问题: "这个 [资源类型] 你已经有了，还是需要我帮你创建？"
选项:
- "我已经有了，告诉我放哪里"
- "需要你帮我创建"
```

**Phase 3 完成标志**：所有文件创建完成

---

## Phase 4: 测试与迭代 (Validation & Iteration)

### 4.1 设计测试提问

Skill 测试就是设计一个能触发它的提问。使用 `AskUserQuestion` 询问：

```
问题: "我们来测试一下这个 Skill。你平时会怎么向 Claude 提出这类请求？"
选项:
- "我来说一个典型的请求"
- "帮我想几个测试用例"
```

若用户选择"帮我想"，根据 Skill 功能生成 3 个测试提问：
1. **正常请求**: 最典型的使用场景
2. **边缘情况**: 特殊输入或复杂需求
3. **不应触发**: 相似但不相关的请求（验证不会误触发）

### 4.2 执行测试

使用 `AskUserQuestion` 让用户选择：

```
问题: "选择一个测试提问来验证 Skill："
选项:
- "[正常请求的具体提问]"
- "[边缘情况的具体提问]"
- "[不应触发的具体提问]"
- "跳过测试"
```

执行测试后，观察 Skill 是否被正确触发、输出是否符合预期。

### 4.3 迭代优化

使用 `AskUserQuestion` 询问：

```
问题: "测试结果怎么样？"
选项:
- "很好，完成了"
- "有点问题，我说一下"
- "完全不对，重新来"
```

**迭代提示**：
- 如果 Skill 没被触发 → 检查 description 是否包含触发关键词
- 如果输出不对 → 检查 SKILL.md body 的指令是否清晰
- 如果误触发 → 让 description 更具体

---

## 核心设计原则

### 简洁至上

上下文窗口是公共资源。每个 token 都要问：
- "Claude 真的需要这个解释吗？"
- "这段内容值得占用 token 吗？"

### 自由度匹配

| 自由度 | 适用场景 | 示例 |
|--------|----------|------|
| 高 | 多种方法都可行 | 代码审查流程 |
| 中 | 有首选模式但允许变化 | 带参数的脚本 |
| 低 | 操作脆弱、一致性关键 | 数据库迁移 |

### 渐进式披露

三级加载系统：
1. **元数据** (name + description) - 始终在上下文 (~100词)
2. **SKILL.md body** - 触发时加载 (<5k词)
3. **Bundled resources** - 按需加载 (无限制)

---

## 参考资源

- **编写最佳实践**: 见 [references/best-practices.md](references/best-practices.md) - 命名规范、简洁原则、反模式、质量检查清单
- **多步骤流程设计**: 见 [references/workflows.md](references/workflows.md)
- **输出格式模式**: 见 [references/output-patterns.md](references/output-patterns.md)
- **交互设计指南**: 见 [references/interaction-guide.md](references/interaction-guide.md) - AskUserQuestion 最佳实践