pm-skill-creator

目的

以互动方式走完完整的技能设计流程——从原始想法或内容，到符合仓库规范、结构清晰的 SKILL.md 草稿。通过自适应提问确定技能类型、范围、结构和内容，然后生成可供验证的草稿。

这项技能会陪你一起梳理，先弄清楚要构建什么，再着手构建——通过对话将原始想法或内容整理成合适的结构，然后生成一份可供你验证的草稿。

核心概念

三种技能类型（判定标准）

• 组件：单个产物或模板。可独立使用。供其他技能引用。请问：“这是某人会创建的东西吗？”
• 互动型：通过引导式对话提出自适应问题，并给出编号建议。请问：“要发挥作用，是否需要来回交流？”
• 工作流：引用其他技能的多阶段编排。请问：“这是否会协调多个步骤中的多项活动？”

技能结构（不可缺少的部分）

每项技能都必须按以下顺序包含这些部分：

1. 目的 — 说明它的作用及使用时机（聚焦结果）
2. 核心概念 — 框架、定义、思维模型
3. 应用 — Agent 可遵循的分步说明
4. 示例 — 至少一个具体、明确的示例
5. 常见陷阱 — 明确指出失败模式及其后果和解决方法
6. 参考资料 — 相关技能、外部框架、源材料

元数据限制

• name：小写 kebab-case，≤ 64 个字符
• description：≤ 200 个字符，必须包含触发提示（“Use when...”）
• intent：面向仓库的较长摘要（无字符数限制）
• type：只能是 component、interactive 或 workflow

引导流程

按照此互动流程，以引导式对话的方式运行这项技能：

• 先用一句话简要说明，然后提供一种开始方式：引导式（每次问一个问题）、一次性提供上下文（用户一次性粘贴所有内容）或最佳猜测（仅根据主题继续）。
• 每轮用通俗语言只问一个问题；等待回答后再问下一个。切勿将多个问题合并提问。
• 在每个问题中标明进度（例如 Context Q1/5）。
• 每个问题都提供编号选项和推荐的默认选项；适用时加入“其他（请说明）”。
• 妥善处理对话中断，并允许用户暂停后继续。
• 在决策点提供编号建议，而不是只给出单一方案。

应用

这项互动技能最多会提出 5 个自适应问题，然后交付一份完整的 SKILL.md 草稿，包含 frontmatter、所有必需部分，以及符合仓库规范的结构。

---

步骤 0：开始会话

Agent 说：

“我会帮你从零开始设计一项新的 PM 技能。整个过程大约需要 10–15 分钟，最多会问 5 个问题。你想如何开始？

1. 引导式 — 我每次问一个问题，根据你的回答构建技能（推荐）
2. 一次性提供上下文 — 粘贴原始内容、笔记或框架，我会据此提出技能结构
3. 最佳猜测 — 只告诉我主题，我会先起草一份技能供你完善”

---

问题 1：原始材料是什么？（Q1/5）

Agent 问：

“我们要把什么转化成一项技能？把你现有的内容告诉我即可。”

1. 框架或思维模型 — 一种处理 PM 问题的结构化思考方法（例如优先级矩阵、决策树）
2. 模板或产物 — PM 创建的交付物（例如 PRD 章节、定位陈述、史诗任务格式）
3. 流程或工作流 — 完成 PM 任务的多步骤方法（例如探索冲刺、路线图规划）
4. 指导或咨询主题 — PM 需要引导式自适应帮助的领域（例如干系人协调、定价决策）

或者用你自己的话描述现有内容。

Agent 备注： 如果用户直接粘贴原始内容，而不是选择某个选项，请分析内容并推断答案。继续之前，请先确认你的理解。

问题 2：技能类型决策（Q2/5）

根据 Q1 的回答，Agent 推荐一种类型并进行确认：

如果 Q1 = 框架或模板：

“这听起来像是一个组件技能——一个独立的产物或参考资料。它会包含模板、质量标准和示例。这样合适吗？还是我遗漏了什么对话式／自适应元素？

1. 是，组件技能——它是一个独立的交付物或参考资料
2. 实际上，它需要对话——用户需要通过引导式提问才能很好地使用它（→ 交互式）
3. 它不止一个产物——它会编排多个步骤或其他技能（→ 工作流）”

如果 Q1 = 流程或工作流：

“这听起来像是一个工作流技能——一个多阶段流程。它会引用或编排其他独立的技能／产物吗？还是更像一场引导式对话？

1. 是，工作流技能——它有明确的阶段，也可能引用其他技能
2. 它更偏对话式——其价值来自自适应提问和建议（→ 交互式）
3. 它比我描述的更简单——实际上它只是一个包含多个步骤的产物（→ 组件）”

如果 Q1 = 指导或建议：

“这听起来像是一个交互式技能——通过引导式提问，根据回答进行调整，最后给出枚举的建议。对吗？

1. 是，交互式技能——要发挥作用，它需要来回对话
2. 它更像参考资料——用户只需要框架，不需要对话（→ 组件）
3. 它是一个完整流程——包含多个阶段，并会编排其他技能（→ 工作流）”

---

问题 3：范围和命名（Q3/5）

Agent 提问：

“这个技能应该叫什么？我需要两项信息：

a) 工作名称——小写 kebab-case，最多 64 个字符（例如，feature-investment-advisor、user-story、discovery-process）

b) 一句话描述——它的功能 + 适用场景。必须不超过 200 个字符，并以动词或“Use when...”开头。

请给出你认为最好的版本；如有需要，我会帮你润色。或者只需描述技能的用途，我会为这两项内容提供建议。”

**Agent 备注：**继续前，验证名称格式（kebab-case，≤ 64 个字符）和描述长度（≤ 200 个字符）。如果其中任一项不符合要求，请提出修改建议。

---

问题 4：关键内容（Q4/5）

此问题会根据 Q2 中的技能类型进行调整：

对于组件技能：

“这个产物或框架的核心要素有哪些？我需要：

1. 模板或结构——它包含哪些章节／字段？
2. 质量标准——什么样的算好，什么样的算差？
3. 一个具体示例——展示如何编写一份出色的完整内容

请提供你目前已有的内容，无论是项目符号、粗略笔记，还是完整草稿。”

对于交互式技能：

“请带我梳理一下对话流程：

1. 开场问题是什么？——用户首先需要告诉你什么？
2. 有哪些 2-4 条分支路径？——回答会如何改变后续内容？
3. 会给出哪些建议？——你会提供哪 3-5 种结果？

请按你的理解给出决策树，即使还很粗略也没关系。”

对于工作流技能：

“请梳理各个阶段：

1. 主要步骤有哪些？（通常为 3-6 个阶段）
2. 每个阶段的输入和输出是什么？
3. 会引用哪些现有技能？（继续前，请搜索现有技能，找出是否已有技能涵盖此主题。）
4. 决策点在哪里？

请给出流程，可以是顺序式、分支式，或两者兼有。”

---

问题 5：陷阱和边缘情况（Q5/5）

Agent 提问：

“人们做得不好时会出现什么问题？我需要 2-3 种失败模式：

1. 为失败模式命名——给它一个标签（例如，“指标作秀”“英雄情结”）
2. 描述后果——有人落入这个陷阱时会发生什么？
3. 说明如何修正——应采取什么纠正措施？

如果你不确定，请告诉我你见过的最常见错误，我会帮你整理。”

---

草稿生成

收集完对 Q1-Q5 的回答后，Agent 会生成一份完整的 SKILL.md 草稿，其中包括：

1. YAML 前置元数据 — name、description、intent、type、best_for、scenarios、estimated_time
2. 目的 — 根据 Q1 + Q3 综合得出
3. 关键概念 — 根据 Q4 的内容整理
4. 应用 — 根据 Q4 整理成分步说明
5. 示例 — Q4 中的具体示例（若未提供，则生成一个）
6. 常见陷阱 — 根据 Q5 整理
7. 参考资料 — 对话中识别出的相关技能 + 源材料

生成后，Agent 会说：

"这是你的 SKILL.md 草稿。在定稿之前：

1. 审阅草稿 — 它是否准确表达了你的意图？
2. 验证前置元数据 — 确认其中包含 name 和 description，且长度符合限制（name ≤ 64 个字符，使用 kebab-case；description ≤ 200 个字符，并包含“何时使用……”的触发提示）。
3. 确认结构和触发条件 — 确认所有必需章节均已包含，并且 description/触发条件确实能匹配真实的用户请求。
4. 检查重叠 — 确保它没有与现有技能重复。

你想让我做任何调整，还是准备好进行验证了？"

示例

示例：框架 → 组件技能

Q1： “1 — 一个框架。它是一个用于评估自建还是采购决策的 2x2 矩阵。” Q2： “1 — 是，组件技能。” Q3： “名称：build-vs-buy-matrix。描述：‘使用战略价值和实施复杂度构成的 2x2 矩阵评估自建还是采购决策。适用于需要在内部自建和采购解决方案之间做选择时。’” Q4： “坐标轴为战略差异化程度（低/高）和实施复杂度（低/高）。四个象限：采购（低/低）、合作（低/高）、自建（高/低）、投资（高/高）。质量标准：每个象限都有明确的决策规则和一个示例。” Q5： “最大的错误：把它当作一次性决策。后果：你构建了某样东西，市场发生变化，而你却被困在维护缺乏差异化的技术上。改进方法：每季度重新审视。”

输出： 一份完整的组件技能，包含模板、填充后的示例，以及关于季度审视的陷阱。

---

示例：咨询主题 → 交互式技能

Q1： “4 — 一个辅导主题。帮助 PM 处理与领导层的首次定价沟通。” Q2： “1 — 是，交互式。” Q3： “名称：pricing-conversation-advisor。描述：‘为首次与领导层进行定价沟通做好准备。适用于向高管介绍定价调整或新的变现方式时。’” Q4： “开场问题：定价调整是什么？分支：新产品定价、现有产品涨价、从免费增值转为付费、转向按用量计费。建议：需要提供的数据、异议处理、阐述策略。” Q5： “失败模式：‘先报数字’。后果：高管会盯着价格点，而不是关注策略。改进方法：在透露数字前，务必先说明商业理由和对客户的影响。”

输出： 一份完整的交互式技能，包含 3 个问题的流程、4 个分支，以及每个分支对应的编号建议。

---

反模式：范围蔓延

Q1： “我想要一个涵盖所有产品战略的技能——愿景、路线图、OKR、优先级排序、利益相关方协同和指标。”

Agent 的回复： “这应拆成 4-6 个独立技能，而不是一个。我们先选出当前最重要的一项，然后构建它。哪一项最紧迫？

1. 愿景 → 组件技能
2. 路线图规划 → 工作流技能（已有：roadmap-planning）
3. 优先级排序 → 交互式技能（已有：prioritization-advisor）
4. 其他

从一个开始。之后我们可以构建其他技能。”

常见陷阱

陷阱 1：类型混淆

症状： 把某个东西称为“工作流”，但它实际上只是一个包含编号步骤的模板。

后果： 技能过度设计，引用了不存在的子技能，还会让用户困惑。

解决方法： 诚实地应用 Q2 中的类型判断问题。如果它不负责协调其他技能，也没有输入和输出各不相同的明确阶段，那它很可能是一个组件。

陷阱 2：无法触发的描述

症状： 描述只说明技能是什么（“用于定价决策的框架”），却没有说明何时使用。

后果： Claude 无法将用户请求与该技能匹配起来，导致它一直闲置。

解决方法： 每条描述都必须回答“何时使用……”——例如：“使用结构化框架评估定价决策。适用于在不同定价模式之间做选择，或准备定价方案时。”

陷阱 3：跳过验证

症状：“草稿看起来不错，可以发布了。”

后果： frontmatter 错误、缺少章节、交叉引用失效、目录计数不一致。

解决方法： 务必验证草稿的 frontmatter，并确认所有必需章节都已包含，然后再认定技能已完成。没有例外。

陷阱 4：大杂烩式的范围

症状： 试图把整个领域的内容都塞进一个技能。

后果： 变成一个 500 行的庞然大物，却什么都做不好。范围太广，难以准确触发；内容太长，也不实用。

解决方法： 一个技能 = 一项任务。如果需要超过 6 个应用步骤或超过 4 个分支，你很可能需要多个技能。