Skip to main content الرئيسية المنشئون infometa workbuddyskills skill-creator
skill-creator 专家团内部技能编写工具。按 WorkBuddy Skill 规范自动推导生成完整的 Skill 技能包（SKILL.md + README.md + GUIDE.md + CASES.md + Prompt.md + references/）。由专家团解决方案专家（帅帅/SY）调用，基于任务卡用户需求和已确认设计方向自动填充所有字段，将用户需求转化为可交付的技能产物。当主理人委托技能编写任务、或需要生成符合 U1-U7 质量原则的 Skill 时使用。⚠️ 仅由专家团内部调用，不直接面向终端用户。
الانتقال إلى التثبيت سوق المهارات اكتشف واستكشف مهارات الذكاء الاصطناعي التي بناها المجتمع.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
عرض تفاصيل Prompt يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/infometa/workbuddyskills --skill skill-creatorيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
تحميل Zip جاري التحميل... المهن ذات الصلة SOC
استنادا إلى تصنيف SOC المهني
name skill-creator display_name Skill Creator — WorkBuddy 技能包生成器 display_name_en Skill Creator description 专家团内部技能编写工具。按 WorkBuddy Skill 规范自动推导生成完整的 Skill 技能包（SKILL.md + README.md + GUIDE.md + CASES.md + Prompt.md + references/）。由专家团解决方案专家（帅帅/SY）调用，基于任务卡用户需求和已确认设计方向自动填充所有字段，将用户需求转化为可交付的技能产物。当主理人委托技能编写任务、或需要生成符合 U1-U7 质量原则的 Skill 时使用。⚠️ 仅由专家团内部调用，不直接面向终端用户。 description_zh WorkBuddy 技能包生成器（专家团内部版），按官方标准+已上架技能包实际结构自动推导生成完整 Skill 目录（SKILL.md + README.md + GUIDE.md + CASES.md + Prompt.md + references/）。由专家团解决方案专家调用，基于任务卡信息自动填充元数据、能力边界、工作流程，产出物直接交付主理人。 description_en Internal skill package generator for the SkillHub Charity Expert Team. Auto-derives a complete Skill directory (SKILL.md + README.md + GUIDE.md + CASES.md + Prompt.md + references/) following WorkBuddy standards. Used by the solution architect agent, not directly by end users. category writing version 1.2.0 author Tencent_SSV_Tech4Good license Tencent SSV Internal
Skill Creator — WorkBuddy 技能包生成器
概述
本技能是 SkillHub 公益专家团内部工具 ，由解决方案专家（帅帅/SY）调用，按 WorkBuddy Skill 标准通过交互式采集生成完整的 Skill 包目录。产出物直接交付给专家团主理人（星星），不经过公开市场上架流程。
核心原则 ：Skill 是纯文本的提示词工程，不需要写代码 。本工具将用户需求转化为结构化的 Markdown 技能定义。
能力边界
✅ 能做什么
按 PDF 标准生成完整 Skill 包目录（SKILL.md + references/+ scripts/）
引导分阶段采集 Skill 信息（元数据、能力边界、工作流、参考资料）
应用 PDF §3.3 的 5 项最佳实践（明确边界、拆分步骤、补充资料、增加示例、本地验证提醒）
按 PDF §4.1 准入标准做质量验证（SKILL.md 完整性、能力边界清晰、指令可执行、中文友好等）
自动注入默认安全基线（API 密钥不硬编码、敏感信息脱敏、权限说明）
❌ 不做什么
不创建专家包（请使用 expert-creator）
不直接对终端用户提供服务（本工具由专家团内部调用，产出物经主理人审核后交付）
不替代 PDF 中规定的"本地反复验证"环节（最佳 3-5 轮迭代仍需用户自行测试）
不生成代码 Skill 中的具体业务逻辑代码（仅提供脚本目录结构与样板）
核心约束
Skill 包目录结构（对齐 WorkBuddy 市场标准上架结构，红线） ：产物为一个完整目录，必须包含以下 5 个文件 （不是可选项）：
SKILL.md（必须）— 主定义与对话工作流程README.md（必须）— 面向开发者/审核者的技术说明文档（概览、目录结构、安装方式、参数说明、依赖与降级策略）GUIDE.md（必须）— 面向终端用户的使用指南（适用场景、安装配置、效果案例、常见误区 Tips）CASES.md（必须）— 至少 2-3 个完整实践案例（场景背景→问题→解决方案→输入样本→输出结果）Prompt.md（必须）— 至少 5 条示例提示词（中英对照）references/（按技能场景按需生成，非必需）scripts/（按技能场景按需生成，非必需）icons/（由图标设计专家在 Phase 2.5 独立完成，不在本工具职责范围内）
元数据必填 （PDF §4.1）：name / description / category / version / author 五项不可缺失正文 ≥ 200 字 （PDF §4.1）：SKILL.md 指令正文部分必须不少于 200 字，否则审核不通过中文友好 （PDF §4.1）：面向中文用户场景时，描述和指令应以中文为主能力边界清晰 （PDF §3.3）：在 SKILL.md 开头清晰定义 Skill 能做什么、不能做什么API 密钥不硬编码 （PDF §4.2）：涉及 API 调用时不可在 SKILL.md 或 scripts 中硬编码密钥，需通过环境变量或 MCP 配置引入权限说明 （PDF §4.2）：如涉及文件读写、网络请求等，需在元数据或正文中显式声明拆分步骤 （PDF §3.3）：复杂任务必须分成清晰的多步执行流程，每步有明确的输入和输出存储路径 ：默认输出至 ~/.workbuddy/skills/{name}/（用户级）或用户指定的项目目录
工作流程
⚠️ 调用模式说明（红线·必读）
本工具设计文档里的 Phase 1-6 沿用了 WorkBuddy 官方 Skill 创建规范的表述习惯，字面写的是"使用
AskUserQuestion
但这是面向"直接对话式创建"场景的表述，不适用于本工具在专家团内部被解决方案专家（帅帅）调用的场景
帅帅是被主理人 spawn 的团队成员（子会话），不能自己调用 AskUserQuestion （自行调用不会呈现给用户、会导致流程卡死）——这在 skillhub-solution-architect.md 中已是明确红线
帅帅调用本工具时，手上已经有：① 主理人任务卡里的用户需求摘要 ② 步骤3设计思路选型后用户已确认的设计方向 ③ 前序对话中用户透露的所有上下文
因此本工具被内部调用时，Phase 1-6 各"采集"环节的正确执行方式是 ：帅帅基于已有信息自动推导生成 对应字段，不逐项询问用户；只有在推导后仍存在关键性缺失 （如技能命名冲突、category 无法判断、涉及需要用户主观选择的边界性问题）时，才整理成清单交主理人弹卡向用户确认——这与解决方案专家自身文档里"步骤2需求细化"的定位一致（先自行判断，缺失关键信息才走用户确认这条通道）。
下文 Phase 1-6 中出现的"使用 AskUserQuestion 采集"，在内部调用场景下应理解为"基于已知上下文自动推导生成，缺失时才整理为确认清单交主理人 "，而非逐字段发问
Phase 0：前置准备（内部调用时自动确定，不询问）
内部调用时固定按 PDF v2026.4 标准生成
输出目录固定为任务卡指定的技能目录（主理人已在任务卡中给出绝对路径），不询问、不使用默认路径
Phase 1：基础元数据（内部调用时自动推导生成） 基于任务卡的用户需求摘要 + 用户已确认的设计方向，自动推导生成 PDF §4.1 必填字段，不逐项询问：
字段 说明 推导依据 name技术标识符，小写字母+连字符，全局唯一 由技能核心功能提炼（如"志愿者工时记录"→volunteer-hour-tracker），若疑似与已有技能重名，交主理人确认 display_name中文展示名 用户需求摘要中的技能主题直接提炼 display_name_en英文展示名 display_name 的英文翻译description技能描述（AI 用来判断激活时机） 由用户需求摘要 + 设计方向合成，含触发关键词（U1 要求，见下） description_zhdescription_en中英简短介绍 description 的简写版本category10 大场景分类之一 按技能核心功能匹配最接近的分类；无法判断时默认 productivity，不阻塞流程 version语义化版本号 初次交付固定 1.0.0（解决方案专家关键规则已规定） author合作方名称 若任务卡已含用户机构名称则直接使用；若此时机构名称尚未采集（通常在 Phase 4 才采集），先填 {待活动运营专家采集后补充} 占位，不阻塞技能编写本身
⚠️ 仅当以下情况才需交主理人整理清单向用户确认 ：name 疑似与已有技能重名、category 完全无法归类、用户需求本身存在歧义导致无法推导 description。其余情况下必须自动填充完整，不得留空或跳过 ——这是本次修复的核心：此前因照搬"使用 AskUserQuestion 采集"的字面表述，实际执行时既无法真弹卡、又没有自动推导兜底，导致元数据字段缺失或敷衍填充。
Phase 2：能力边界与触发词（内部调用时自动推导生成） 按 PDF §3.3 第 1 条原则：明确能力边界 — 在 SKILL.md 开头清晰定义 Skill 能做什么、不能做什么
基于用户需求摘要 + 设计方向 + U1/U2 质量要求，自动推导生成 ：
能做什么 （3-6 条具体能力）— 从设计方向的核心工作流拆解出具体能力点，写入 ## 能力边界 → ✅ 能做什么不做什么 （3-5 条明确边界）— 基于该技能主题下常见的相邻易混淆场景 推导（如"志愿者工时记录"技能，边界应排除"志愿者招募""捐赠财务对账"等相邻场景），写入 ## 能力边界 → ❌ 不做什么触发关键词 （用户输入哪些词时该 Skill 应该被激活）— 从技能名称、核心功能、用户原话中提炼，用于 description 字段写作（含 U1 要求的负向排除）典型用户场景 （2-3 个"何时使用"场景）— 从用户需求摘要中的具体场景描述提炼 ⚠️ 若用户需求摘要信息量不足以支撑以上推导（如过于模糊，仅一句话未展开），先基于设计方向做合理假设 并标注 [假设：{依据}]，不因信息不足而跳过整个 Phase；假设内容在后续如与用户实际反馈冲突，属于正常整改范畴（见步骤6）。
Phase 3：核心约束与安全要求（内部调用时自动推导生成，安全基线强制注入）
数据来源标准 （如有）— 从任务卡上下文推导数据从哪里获取权限声明 （PDF §4.2）：按技能实际工作流判断是否需要文件读写/网络请求/API 密钥，不臆造不需要的权限 （最小权限原则）铁律 / 强制规则 （1-3 条最重要的行为约束）— 从技能核心场景的风险点推导（如涉及个人信息的技能，铁律应包含"不外泄用户隐私"）降级策略 （外部依赖不可用时如何降级）— 按 U5 通用降级机制表格套用
安全基线强制注入，不因信息不足而省略 ：下方"默认安全基线"章节内容必须原样注入 SKILL.md，这一步不依赖任何用户输入，无需推导也无需确认。
Phase 4：工作流程与步骤拆分（内部调用时自动推导生成） 按 PDF §3.3 第 2 条原则：拆分步骤 — 复杂任务分成清晰的多步执行流程，每步有明确的输入和输出
工作流阶段数 （建议 3-6 个）— 从设计方向的核心工作流直接映射为阶段划分每个阶段的核心动作 + 输入 + 输出 — 基于用户需求摘要中的具体场景描述展开是否需要交互式选项 （用 AskUserQuestion 选项卡）——这里指的是该技能未来面向其终端用户运行时的交互设计 ，与本工具自身"内部调用不弹卡"是两个不同层面的问题，不要混淆；按技能场景是否天然需要用户选择来判断降级路径 （如某步失败如何处理）— 按 U5 通用降级机制表格套用
Phase 5：参考资料、脚本与示例（内部调用时自动推导生成） 按 PDF §3.3 第 3-4 条原则：补充参考资料 + 增加示例
是否需要 references/ 目录？ 按技能场景是否涉及以下内容自动判断，无需询问：
API 文档 / 字段类型说明
知识库快照（必须标注快照日期）
模板（合同、报告、表单等）
工作流详细模板
是否需要 scripts/ 目录？ （仅在需要执行命令行工具或数据处理时，按技能场景自动判断）示例（input → output） ：建议在 SKILL.md 中加入 1-2 组 input → output 示例
Phase 5.5：配套文档生成（红线·必做，不可省略） ⚠️ 本 Phase 是本次修复新增的必做环节 ：此前因核心约束条目未提及以下 4 个文件，导致产出的技能包结构性缺失。下述 4 个文件是每个 Skill 包的标配交付物，与 SKILL.md 同等地位，不因"用户没要求"而省略 ——它们全部基于 SKILL.md 已生成的内容自动映射展开 ，不需要额外询问用户：
README.mdname/version/能力边界/工作流阶段/依赖降级策略等字段直接映射填充GUIDE.mdCASES.md构造 2-3 个完整案例 （场景背景→问题描述→解决方案→输入样本→输出结果），案例中的机构名/项目名等具体信息如无真实素材可参照，按 U6 数据真实性原则标注为示例性质，不得声称是真实发生的案例Prompt.md至少 5 条 中英对照的示例 Prompt
💡 参照样例：charity/skills/公益文书助手/（README.md、GUIDE.md、CASES.md、Prompt.md 均可作为格式参照）
Phase 6：汇总确认 + 生成 Skill 包
展示完整信息摘要 ：以结构化表格展示所有自动推导生成的字段，附在回报主理人的消息中（供主理人审阅，非向用户弹卡确认）仅当 Phase 1-5 中标注了 [假设：...] 或存在关键性缺失时 ，才整理成清单交主理人弹卡向用户确认；其余情况下不产生确认环节 ，直接进入下一步生成生成目录结构 ：
创建 {name}/ 根目录
生成 SKILL.md（按下方模板）
生成 README.md / GUIDE.md / CASES.md / Prompt.md（按 Phase 5.5 生成，红线·不可省略 ）
创建 references/（如有内容）+ 默认子文件
创建 scripts/（如有需要）
质量验证 ：执行下方"质量验证清单"逐项检查（含目录结构完整性检查，5 个必需文件缺一不可）产出物直接交付主理人，由主理人协调后续流程
SKILL.md 标准模板 ---
name: {小写字母+连字符的技术标识符，全局唯一}
display_name: {中文展示名}
display_ name_en: {English Display Name}
description: {一句话技能描述，含触发词，AI 用来判断何时激活}
description_ zh: {简短中文介绍}
description_en: {Brief English introduction}
category: {10 大场景分类之一}
version: 1.0.0
author: {合作方名称}
license: {许可证，可选}
---
# {Skill 中文名称}
## 概述
{一段话描述：本 Skill 是什么、解决什么问题、产出物是什么}
## 能力边界
### ✅ 能做什么
- {具体能力 1}
- {具体能力 2}
- {具体能力 3}
### ❌ 不做什么
- {明确边界 1}
- {明确边界 2}
- {明确边界 3}
## 核心约束
1. **{约束 1}** ：{说明}
2. **{约束 2}** ：{说明}
3. **{约束 3}** ：{说明}
## 工作流程
### 第一阶段 / Step 1：{阶段名}
{核心动作描述}
**输入** ：{用户输入的格式或字段}
**输出** ：{Skill 产出的格式或字段}
### 第二阶段 / Step 2：{阶段名}
（按需 3-6 个阶段，每个阶段明确输入和输出）
## 参考资料（如有）
- `references/{file1}.md` — {用途}
- `references/{file2}.md` — {用途}
## 示例
### 示例 1：{场景名}
**输入** ：
\`\`\`
{用户的输入示例}
\`\`\`
**输出** ：
\`\`\`
{Skill 的输出示例}
\`\`\`
## 安全要求
- API 密钥：{如何引入；不可硬编码}
- 文件读写：{说明范围}
- 网络请求：{说明目标域名}
- 敏感信息：{脱敏要求}
## 降级策略
- 当 {外部依赖} 不可用时：{降级方案}
- 当 {网络请求失败} 时：{降级方案}
## 质量目标
- {可量化指标 1}
- {可量化指标 2}
正文必须 ≥ 200 字 （PDF §4.1）。本模板按层级填充后通常 800-1500 字，已远超下限。
README.md / GUIDE.md / CASES.md / Prompt.md 标准模板 Phase 5.5 生成这 4 个文件时，按 references/companion-docs-templates.md 中的模板填充（含 README/GUIDE/CASES/Prompt 四份完整模板），不在本文件内重复展开。
category 候选值（内部参考）
默认安全基线 当用户不知道如何设计安全要求时，按以下基线注入到 SKILL.md：
## 安全要求
- **API 密钥** ：本 Skill 不直接处理 API 密钥；如调用第三方服务，需通过环境变量或 MCP 配置引入，禁止在 SKILL.md / scripts/ 中硬编码
- **敏感信息** ：涉及身份证号、手机号、签字盖章件等内容时，必须以占位符或脱敏后形式处理，不在对话中直接展示完整内容
- **文件读写** ：仅在用户明确指定的范围内读写文件；禁止读取 ~/.ssh、~/.aws 等敏感目录
- **网络请求** ：仅访问 SKILL.md 中明示的官方域名（如 {示例：techforgood.qq.com}），不向未声明的域名发起请求
- **数据可追溯** ：涉及法规、案例、关键数字时附数据来源或快照日期；禁止编造"看似合理"的事实
通用质量原则（U1-U7，跨场景必备）— 摘要
💡 以下 7 项原则来自 WorkBuddy 官方对多个已上架 Skill 质量反馈的抽象提炼，适用于任何类型的 Skill。完整版（含每条原则的 SKILL.md 必备代码块模板）见 references/quality-principles-u1-u7.md ，生成 Skill 正文时按需读取对应章节。
原则 一句话定义 对应 Phase 自查项 U1 触发精准性description 含正向关键词 + 至少 2 个负向排除场景 Phase 1：自问"哪些相邻场景容易被误触发" U2 能力边界与越界拒绝越界请求主动识别+礼貌拒绝，≥3 条具体边界+拒绝模板 Phase 2：自行推导补全 U3 工具能力契约每个工具/MCP/API 的可用范围、失败降级、禁止替代方式均显式声明 Phase 3：逐一自问可用范围/降级/禁止方式 U4 执行前置校验涉及外部资源的步骤必须"校验→告知→执行"，不得编造结果 Phase 4：自问资源不可用时如何处置 U5 失败降级机制每类失败都有明确阈值+降级动作（工具失败1次、连续否定2次等） Phase 4：覆盖工具失败+资源不可用+连续否定 U6 数据真实性原则不编造事实/数据/场景/合作方，生成型场景需「新增内容标注表」 Phase 5：所有读取/提取/生成/润色步骤强制声明 U7 完整交付保障长文本主动分段、错误友好翻译、结构化输出质量自检 Phase 4：自问输出格式与错误展示方式
兼容映射（旧 Q1-Q6 → 新 U1-U7）及各原则的详细规则模板，见 references/quality-principles-u1-u7.md。
一键检查清单（生成 Skill 时使用） 调用 skill-creator 生成 Skill 后，必须逐项确认：
未通过的项目 → 由帅帅自行补充完善后再交付 （不属于需要用户确认的关键性缺失），不因此产生额外的用户确认环节。
质量验证清单（PDF §4.1 + §4.2）
元数据完整性（必填 5 项 + 推荐 4 项）
内容质量
安全要求
目录结构（红线·5 个必需文件缺一不可）
加分项（内部参考）
异常处理
用户信息不完整 ：对缺失字段提供合理默认值建议，标注"[待专家确认]"用户中途放弃某模块 ：该模块用简化版本填充，标注"[简化版，可后续扩展]"不知道选哪个 category ：默认使用 productivity（提效），后续可由主理人确认工作流过于复杂 ：拆分为多个 Skill（每个 Skill 聚焦一个核心能力），由专家团主理人协调编排 