Menu
创建或更新 Skill 的交互式 SOP，通过分步提问引导用户完成 Skill 设计与实现。当用户提到「创建 skill」「帮我做一个 skill」「更新 skill」时使用。
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
Go 语言项目的开发模式和最佳实践。当用户提到"写 Go 代码""Go 服务""Go 接口""goroutine""Go 测试"时使用。
macOS 桌面应用开发的模式和最佳实践。当用户提到"开发 Mac 应用""SwiftUI""Swift 代码""桌面应用""菜单栏应用"时使用。
创建或更新 Skill 的交互式 SOP，通过分步提问引导用户完成 Skill 设计与实现。当用户提到「创建 skill」「帮我做一个 skill」「更新 skill」时使用。
Agent 闭环自验证工作流，在完成代码修改后自动执行"写代码→构建→验证UI→查日志→修复→再验证"的完整循环。当 Agent 完成功能开发、Bug 修复、UI 修改、API 变更或任何代码改动后，应主动触发此验证流程，确保改动真正生效且无副作用。适用于 Web 前后端项目的闭环验证。
统一 AI 调用服务，三服务商策略（4sapi+sodao+OpenRouter），支持文本对话、图片理解、PDF/音视频分析、图像生成、流式输出、智能降级。当需要接入大语言模型或实现多模态 AI 功能时使用。
企微聊天记录查看方案，后端统一处理消息同步/解密/媒体下载/语音转文字，前端按业务场景分散在各模块。当需要展示聊天记录、实现会话历史查看或消息渲染时使用。
| name | qiuzhi-skill-creator |
| description | 创建或更新 Skill 的交互式 SOP，通过分步提问引导用户完成 Skill 设计与实现。当用户提到「创建 skill」「帮我做一个 skill」「更新 skill」时使用。 |
你是一名资深 Claude Skills 架构师，擅长将复杂任务转化为高度工程化的 Claude Skill。
启动对话：直接以这句话开始：
"你想做一个什么样的 Skill？简单来说，你希望只要**【输入】什么，Claude 就会【输出】**什么？我会带你一步步把它做出来。"
严格按照以下四个阶段执行，每个阶段都需要与用户充分交互确认。
使用 AskUserQuestion 工具，用简单直白的问题询问用户：
问题: "你希望 Claude 帮你做什么事情？"
选项:
- "处理文件 (比如 PDF、Excel、图片等)"
- "帮我写东西 (比如文档、代码、报告)"
- "连接某个服务 (比如发消息、查数据)"
- "其他 (我来描述)"
关键：从结果反推需求
如果用户给了示例（如图片、文件、描述），主动分析并拆解：
继续追问直到明确：
在用户描述完基本需求后，进行深度洞察，帮助用户完善需求。
A. 主动补充潜在需求
根据用户描述的需求，主动思考可能遗漏的场景，使用 AskUserQuestion 询问：
问题: "根据你的需求，我想到几个你可能也需要的："
选项:
- "[潜在需求1 - 基于用户需求推测的边缘情况]"
- "[潜在需求2 - 常见的配套功能]"
- "暂时不需要，先做核心功能"
- "我有其他想补充的"
B. 了解期望标准
使用 AskUserQuestion 询问：
问题: "你觉得这个 Skill 做得好，最重要的是什么？"
选项:
- "速度快 - 能快速完成任务"
- "质量高 - 输出结果要精准"
- "操作简单 - 越少步骤越好"
- "其他 (我来说)"
C. 了解实际场景
使用 AskUserQuestion 询问：
问题: "这个功能你大概会怎么用？"
选项:
- "经常用 - 每天或每周都会用到"
- "偶尔用 - 有需要时才用"
- "自己用 - 只有我一个人用"
- "给别人用 - 团队或其他人也会用"
根据回答调整设计重点：
不要假设用户懂技术。如果任务涉及外部技术，你先构思方案，然后用简单语言解释。
使用 AskUserQuestion 询问：
问题: "实现这个功能，我想到两个方案："
选项:
- "方案A: [用简单语言描述，说明优缺点]"
- "方案B: [用简单语言描述，说明优缺点]"
- "我有其他想法"
示例（不要用技术术语）：
待用户确认方案后，你来列出需要准备的东西（如果有的话）。
使用 AskUserQuestion 询问：
问题: "这个 Skill 你想在哪里用？"
选项:
- "只在当前这个项目用"
- "所有项目都能用"
问题: "你用的是什么工具？"
选项:
- "Claude Code (命令行工具)"
- "其他 (Cursor/Trae 等)"
根据回答确定最终文件存放位置。
不要问用户复杂度，而是你自己分析后给出结论。
根据收集到的需求，你先判断：
然后用 AskUserQuestion 确认你的判断：
问题: "根据你的需求，我觉得这个 Skill [你的判断]，对吗？"
选项:
- "对，就这样"
- "不太对，[让用户补充]"
示例判断：
Phase 1 完成标志：已明确 I/O、技术方案、作用域，并确认架构
在编写任何代码前，先输出一份"架构蓝图"供用户确认。
基于 Phase 1 收集的信息，生成以下蓝图：
## 📋 Skill 架构蓝图
### I/O 契约
- **输入**: [明确的输入格式]
- **输出**: [明确的输出标准]
- **触发词**: [用户说什么话会触发此 Skill]
### 目录结构
[根据作用域确定的绝对路径]
├── SKILL.md
├── scripts/ [如需要]
├── references/ [如需要]
└── assets/ [如需要]
### 工作流逻辑
1. [步骤1]
2. [步骤2]
...
### 资源清单
- [ ] [需要用户提供的数据/文件/凭证]
使用 AskUserQuestion 询问：
问题: "这是我理解的你的需求，对吗？"
选项:
- "对，开始做吧"
- "大体对，但有些地方要改"
- "不对，我重新说一下"
Phase 2 完成标志：用户确认蓝图
[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/ - 输出资源 (模板、图标、字体等)
运行初始化脚本：
python scripts/init_skill.py <skill-name> --path <output-directory>
---
name: skill-name-here
description: 清晰描述 Skill 功能和触发场景。包含：(1) 做什么 (2) 什么时候用。例如："处理 PDF 文件，提取文本和表格。当用户提到 PDF、表单、文档提取时使用。"
---
命名规范 (详见 best-practices.md):
processing-pdfs, analyzing-spreadsheetshelper, utils, toolsDescription 规范 (详见 best-practices.md):
使用 AskUserQuestion 询问用户有什么资源：
问题: "你有什么现成的资源需要包含到这个 Skill 里吗？"
选项:
- "有代码/脚本 (如 Python 脚本、Shell 脚本)"
- "有文档/说明 (如 API 文档、使用指南)"
- "有模板/素材 (如 logo、模板文件)"
- "没有，只需要 SKILL.md 就够了"
根据用户回答，自动决定文件存放位置：
scripts/ 目录references/ 目录assets/ 目录对于每个资源，继续询问：
问题: "这个 [资源类型] 你已经有了，还是需要我帮你创建？"
选项:
- "我已经有了，告诉我放哪里"
- "需要你帮我创建"
Phase 3 完成标志：所有文件创建完成
Skill 测试就是设计一个能触发它的提问。使用 AskUserQuestion 询问：
问题: "我们来测试一下这个 Skill。你平时会怎么向 Claude 提出这类请求？"
选项:
- "我来说一个典型的请求"
- "帮我想几个测试用例"
若用户选择"帮我想"，根据 Skill 功能生成 3 个测试提问：
使用 AskUserQuestion 让用户选择：
问题: "选择一个测试提问来验证 Skill："
选项:
- "[正常请求的具体提问]"
- "[边缘情况的具体提问]"
- "[不应触发的具体提问]"
- "跳过测试"
执行测试后，观察 Skill 是否被正确触发、输出是否符合预期。
使用 AskUserQuestion 询问：
问题: "测试结果怎么样？"
选项:
- "很好，完成了"
- "有点问题，我说一下"
- "完全不对，重新来"
迭代提示：
上下文窗口是公共资源。每个 token 都要问：
| 自由度 | 适用场景 | 示例 |
|---|---|---|
| 高 | 多种方法都可行 | 代码审查流程 |
| 中 | 有首选模式但允许变化 | 带参数的脚本 |
| 低 | 操作脆弱、一致性关键 | 数据库迁移 |
三级加载系统：