菜单
专家团内部技能编写工具。按 WorkBuddy Skill 规范自动推导生成完整的 Skill 技能包（SKILL.md + README.md + GUIDE.md + CASES.md + Prompt.md + references/）。由专家团解决方案专家（帅帅/SY）调用，基于任务卡用户需求和已确认设计方向自动填充所有字段，将用户需求转化为可交付的技能产物。当主理人委托技能编写任务、或需要生成符合 U1-U7 质量原则的 Skill 时使用。⚠️ 仅由专家团内部调用，不直接面向终端用户。
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/infometa/workbuddyskills --skill skill-creator命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
快速生成公司一页纸概览（Tearsheet），涵盖业务描述、关键财务、估值、股东结构和近期催化。 触发词：公司速览、tearsheet、公司概况、一页纸、公司简介、company overview、快速了解、公司画像
构建DCF现金流折现模型和三表财务模型（利润表、资产负债表、现金流量表联动）。 触发词：DCF、现金流折现、财务建模、三表模型、估值模型、WACC、自由现金流、financial model、valuation model
盈利分析技能，支持两种模式： - Preview 模式：业绩发布前的前瞻分析、情景假设、关键观测指标 - Analysis 模式：业绩发布后的深度解读、Beat/Miss 分析、估计修正 触发词：earnings analysis、earnings preview、业绩分析、业绩前瞻、财报分析、季报解读、pre-earnings、post-earnings、Q1/Q2/Q3/Q4 results
基于 SOC 职业分类
正在显示 SKILL.md
| 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 |
本技能是 SkillHub 公益专家团内部工具，由解决方案专家（帅帅/SY）调用，按 WorkBuddy Skill 标准通过交互式采集生成完整的 Skill 包目录。产出物直接交付给专家团主理人（星星），不经过公开市场上架流程。
核心原则：Skill 是纯文本的提示词工程，不需要写代码。本工具将用户需求转化为结构化的 Markdown 技能定义。
expert-creator）SKILL.md（必须）— 主定义与对话工作流程README.md（必须）— 面向开发者/审核者的技术说明文档（概览、目录结构、安装方式、参数说明、依赖与降级策略）GUIDE.md（必须）— 面向终端用户的使用指南（适用场景、安装配置、效果案例、常见误区 Tips）CASES.md（必须）— 至少 2-3 个完整实践案例（场景背景→问题→解决方案→输入样本→输出结果）Prompt.md（必须）— 至少 5 条示例提示词（中英对照）references/（按技能场景按需生成，非必需）scripts/（按技能场景按需生成，非必需）icons/（由图标设计专家在 Phase 2.5 独立完成，不在本工具职责范围内）name / description / category / version / author 五项不可缺失~/.workbuddy/skills/{name}/（用户级）或用户指定的项目目录本工具设计文档里的 Phase 1-6 沿用了 WorkBuddy 官方 Skill 创建规范的表述习惯，字面写的是"使用 采集"——：
AskUserQuestionskillhub-solution-architect.md 中已是明确红线category 无法判断、涉及需要用户主观选择的边界性问题）时，才整理成清单交主理人弹卡向用户确认——这与解决方案专家自身文档里"步骤2需求细化"的定位一致（先自行判断，缺失关键信息才走用户确认这条通道）。AskUserQuestion 采集"，在内部调用场景下应理解为"基于已知上下文自动推导生成，缺失时才整理为确认清单交主理人"，而非逐字段发问基于任务卡的用户需求摘要 + 用户已确认的设计方向，自动推导生成 PDF §4.1 必填字段，不逐项询问：
| 字段 | 说明 | 推导依据 |
|---|---|---|
name | 技术标识符，小写字母+连字符，全局唯一 | 由技能核心功能提炼（如"志愿者工时记录"→volunteer-hour-tracker），若疑似与已有技能重名，交主理人确认 |
display_name | 中文展示名 | 用户需求摘要中的技能主题直接提炼 |
display_name_en | 英文展示名 | display_name 的英文翻译 |
description | 技能描述（AI 用来判断激活时机） | 由用户需求摘要 + 设计方向合成，含触发关键词（U1 要求，见下） |
description_zh / description_en | 中英简短介绍 | description 的简写版本 |
category | 10 大场景分类之一 | 按技能核心功能匹配最接近的分类；无法判断时默认 productivity，不阻塞流程 |
version | 语义化版本号 | 初次交付固定 1.0.0（解决方案专家关键规则已规定） |
author | 合作方名称 | 若任务卡已含用户机构名称则直接使用；若此时机构名称尚未采集（通常在 Phase 4 才采集），先填 {待活动运营专家采集后补充} 占位，不阻塞技能编写本身 |
⚠️ 仅当以下情况才需交主理人整理清单向用户确认：name 疑似与已有技能重名、category 完全无法归类、用户需求本身存在歧义导致无法推导 description。其余情况下必须自动填充完整，不得留空或跳过——这是本次修复的核心：此前因照搬"使用 AskUserQuestion 采集"的字面表述，实际执行时既无法真弹卡、又没有自动推导兜底，导致元数据字段缺失或敷衍填充。
按 PDF §3.3 第 1 条原则：明确能力边界 — 在 SKILL.md 开头清晰定义 Skill 能做什么、不能做什么
基于用户需求摘要 + 设计方向 + U1/U2 质量要求，自动推导生成：
## 能力边界 → ✅ 能做什么## 能力边界 → ❌ 不做什么description 字段写作（含 U1 要求的负向排除）⚠️ 若用户需求摘要信息量不足以支撑以上推导（如过于模糊，仅一句话未展开），先基于设计方向做合理假设并标注 [假设：{依据}]，不因信息不足而跳过整个 Phase；假设内容在后续如与用户实际反馈冲突，属于正常整改范畴（见步骤6）。
按 PDF §4.2 安全要求：
自动推导生成：
安全基线强制注入，不因信息不足而省略：下方"默认安全基线"章节内容必须原样注入 SKILL.md，这一步不依赖任何用户输入，无需推导也无需确认。
按 PDF §3.3 第 2 条原则：拆分步骤 — 复杂任务分成清晰的多步执行流程，每步有明确的输入和输出
自动推导生成：
AskUserQuestion 选项卡）——这里指的是该技能未来面向其终端用户运行时的交互设计，与本工具自身"内部调用不弹卡"是两个不同层面的问题，不要混淆；按技能场景是否天然需要用户选择来判断按 PDF §3.3 第 3-4 条原则：补充参考资料 + 增加示例
自动推导生成：
⚠️ 本 Phase 是本次修复新增的必做环节：此前因核心约束条目未提及以下 4 个文件，导致产出的技能包结构性缺失。下述 4 个文件是每个 Skill 包的标配交付物，与 SKILL.md 同等地位，不因"用户没要求"而省略——它们全部基于 SKILL.md 已生成的内容自动映射展开，不需要额外询问用户：
README.md（技术说明文档，面向开发者/审核者）：按下方「README.md 标准模板」，从已生成的 SKILL.md 中提取 name/version/能力边界/工作流阶段/依赖降级策略等字段直接映射填充GUIDE.md（使用指南，面向终端用户）：按下方「GUIDE.md 标准模板」，把 SKILL.md 的能力边界和工作流转译为终端用户视角的"适用场景/安装步骤/效果说明/常见误区"CASES.md（实践案例）：按下方「CASES.md 标准模板」，基于任务卡的用户需求场景，构造 2-3 个完整案例（场景背景→问题描述→解决方案→输入样本→输出结果），案例中的机构名/项目名等具体信息如无真实素材可参照，按 U6 数据真实性原则标注为示例性质，不得声称是真实发生的案例Prompt.md（示例提示词）：按下方「Prompt.md 标准模板」，从任务卡用户需求 + Phase 2 的典型用户场景中提炼至少 5 条中英对照的示例 Prompt💡 参照样例：
charity/skills/公益文书助手/（README.md、GUIDE.md、CASES.md、Prompt.md 均可作为格式参照）
[假设：...] 或存在关键性缺失时，才整理成清单交主理人弹卡向用户确认；其余情况下不产生确认环节，直接进入下一步生成{name}/ 根目录SKILL.md（按下方模板）README.md / GUIDE.md / CASES.md / Prompt.md（按 Phase 5.5 生成，红线·不可省略）references/（如有内容）+ 默认子文件scripts/（如有需要）---
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 字，已远超下限。
Phase 5.5 生成这 4 个文件时，按 references/companion-docs-templates.md 中的模板填充（含 README/GUIDE/CASES/Prompt 四份完整模板），不在本文件内重复展开。
当用户不知道如何设计安全要求时，按以下基线注入到 SKILL.md：
## 安全要求
- **API 密钥**：本 Skill 不直接处理 API 密钥；如调用第三方服务，需通过环境变量或 MCP 配置引入，禁止在 SKILL.md / scripts/ 中硬编码
- **敏感信息**：涉及身份证号、手机号、签字盖章件等内容时，必须以占位符或脱敏后形式处理，不在对话中直接展示完整内容
- **文件读写**：仅在用户明确指定的范围内读写文件；禁止读取 ~/.ssh、~/.aws 等敏感目录
- **网络请求**：仅访问 SKILL.md 中明示的官方域名（如 {示例：techforgood.qq.com}），不向未声明的域名发起请求
- **数据可追溯**：涉及法规、案例、关键数字时附数据来源或快照日期；禁止编造"看似合理"的事实
💡 以下 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-creator 生成 Skill 后，必须逐项确认：
未通过的项目 → 由帅帅自行补充完善后再交付（不属于需要用户确认的关键性缺失），不因此产生额外的用户确认环节。
生成 Skill 包后，必须逐项检查：
name：小写字母+连字符，全局唯一description：一句话描述含触发词category：从 10 大分类中选一个version：语义化版本号（如 1.0.0）author：合作方名称display_name / display_name_en：中英展示名（推荐）description_zh / description_en：中英详细介绍（推荐）SKILL.md 在根目录README.md 在根目录（技术说明文档，见 Phase 5.5）GUIDE.md 在根目录（终端用户使用指南，见 Phase 5.5）CASES.md 在根目录（至少 2-3 个实践案例，见 Phase 5.5）Prompt.md 在根目录（至少 5 条示例提示词，见 Phase 5.5）references/scripts/icons/（推荐 32×32 PNG，由图标设计专家在 Phase 2.5 完成，非本工具产出）.git、.DS_Store、__pycache__ 等垃圾文件productivity（提效），后续可由主理人确认