有 PM 技能想法或原始素材时，通过引导式对话产出合规的…

把产品经理技能的粗略想法、框架或原始笔记，用最多 5 个自适应问题整理成可直接校验的 SKILL.md 草稿。

适用场景

解决思路

1. 接收技能种子输入：让用户提供想法、框架或原始内容（笔记、提示序列、文章）；也可补充疑似技能类型、目标用户、相关现有技能。若用户在请求中内联提供素材（例如 `help me design a skill from my pricing-tiers framework`），直接把它作为 Q1 答案，不重复提问；若没有输入，开场先问想帮用户完成什么。
2. 使用 `workshop-facilitation` 作为默认交互协议：开场给出会话提示和入口模式（Guided、Context dump、Best guess）；一次只问一个问题，用平实语言；显示进度标签（如 Context Q1/5）；处理打断和暂停/恢复；在决策点给出编号建议；提供编号快捷选项，必要时包含 `Other (specify)`。
3. Step 0 会话开始：向用户说明「我会帮你从零设计一个 PM 技能，约 10-15 分钟、最多 5 个问题」，并给出入口选项：1. Guided——逐个提问并根据回答构建技能（推荐）；2. Context dump——粘贴原始内容、笔记或框架，让代理提出技能结构；3. Best guess——只给主题，先起草可优化技能。
4. Q1/5 询问原始素材：问「我们要把什么变成技能？把你有的都给我。」选项包括：1. 框架或心智模型（如优先级矩阵、决策树）；2. 模板或交付物（如 PRD 章节、定位声明、史诗格式）；3. 流程或工作流（如发现冲刺、路线图规划）；4. 辅导或咨询主题（如干系人导航、定价决策）。也可让用户用自己的话描述。
5. Q1 代理注意：如果用户粘贴原始内容而不是选项，分析内容并推断答案；在继续前先确认你的理解。
6. Q2/5 技能类型决策：根据 Q1 推荐一种类型并让用户确认。若 Q1 是框架或模板，推荐 component 技能（自包含交付物或参考，包含模板、质量标准、示例），并问是否有会话/自适应元素：有则 interactive，比一个交付物更大且编排多步骤/其他技能则 workflow。
7. Q2/5 若 Q1 是流程或工作流，推荐 workflow 技能（多阶段流程），并问它是否引用/编排其他离散技能或交付物，还是更像引导式对话：是 workflow 则保留，更会话化则 interactive，更简单则 component。
8. Q2/5 若 Q1 是辅导或咨询主题，推荐 interactive 技能（根据回答自适应的引导问题，并以枚举建议结束），并问是否需要来回对话才有用：是则 interactive，更像参考则 component，是完整流程则 workflow。
9. 应用三种技能类型判定标准：component——一个交付物或模板、自包含、被其他技能引用，问「这是不是某人要创建的东西？」；interactive——引导式对话、自适应问题、枚举建议，问「这是否需要来回沟通才有用？」；workflow——多阶段编排、引用其他技能，问「这是否跨步骤协调多个活动？」
10. Q3/5 范围与命名：让用户给出 a) working name——lowercase-kebab-case、最多 64 字符（如 `feature-investment-advisor`、`user-story`、`discovery-process`）；b) 一句话描述——说明做什么 + 何时用，最多 200 字符，以动词或 `Use when...` 开头。如果用户只描述目的，则代拟名称和描述。
11. Q3 代理注意：在继续前校验名称格式（kebab-case、≤64 字符）和描述长度（≤200 字符）；任一项不合格就提出修正。
12. Q4/5 component 内容：问交付物或框架的核心元素，包括 1) 模板或结构——包含哪些章节/字段；2) 质量标准——好与坏的区别；3) 一个具体示例——填好的优秀版本；最好再要或生成一个来自不同业务领域的示例（一个 SaaS、一个工业/非 SaaS），避免技能悄悄教成「只适用于 SaaS」。使用仓库的虚构世界，并按领域命名第二个文件（`sample-industrial.md`）；所有示例公司必须虚构。
13. Q4/5 interactive 内容：让用户走一遍对话流程，包括 1) 开场问题——用户首先需要告诉什么；2) 2-4 条分支路径——回答如何改变后续；3) 浮现的建议——会提供哪 3-5 个结果。即使粗糙，也先拿到决策树。
14. Q4/5 workflow 内容：让用户梳理阶段，包括 1) 主要步骤（通常 3-6 个阶段）；2) 每个阶段的输入和输出；3) 引用哪些现有技能（用 `scripts/find-a-skill.sh --keyword <topic>` 检查）；4) 决策点在哪里。拿到流程——顺序、分支或两者兼有。
15. Q5/5 陷阱与边界情况：问「人们做这件事做得差时会出现什么问题？」，需要 2-3 个失败模式：1) 命名失败——给标签（如 `Metrics Theater`、`Hero Syndrome`）；2) 描述后果——掉进去会发生什么；3) 说明修复——纠正动作。若用户不确定，让用户说最常见错误，再帮忙结构化。
16. 草稿生成：收集 Q1-Q5 后生成完整 SKILL.md 草稿，包括 YAML frontmatter：`name`、`description`、`intent`、`type`、`best_for`、`scenarios`、`estimated_time`。
17. 草稿生成：写 Purpose——由 Q1 + Q3 综合而来。
18. 草稿生成：写 Input——由 Q2/Q3 推导：用户提供什么、一个调用示例、以及内联输入规则（用户已提供的内容直接使用，不重复提问）。Input 必须读起来像邀请：零输入也可以，引导流程会覆盖；只用平实语言，不要运行时模板语法如 `$ARGUMENTS`。
19. 草稿生成：写 Key Concepts——根据 Q4 内容结构化。
20. 草稿生成：写 Application——根据 Q4 推导分步说明。
21. 草稿生成：写 Examples——使用 Q4 的具体示例（未提供则生成）；双领域（SaaS + 工业/非 SaaS）是完整打磨的质量标准。
22. 草稿生成：写 Common Pitfalls——根据 Q5 结构化。
23. 草稿生成：写 References——对话中识别的相关技能 + 源材料。
24. 生成后向用户说明：1) 检查草稿是否抓住意图；2) 运行校验 `python3 scripts/check-skill-metadata.py skills/<name>/SKILL.md`；3) 检查触发 `python3 scripts/check-skill-triggers.py skills/<name>/SKILL.md --show-cases`；4) 冒烟测试 `./scripts/test-a-skill.sh --skill <name> --smoke`；5) 问是否需要调整，或是否准备校验。
25. 确保每个技能按顺序包含不可协商的章节：Purpose、Input、Key Concepts、Application、Examples、Common Pitfalls、References。
26. 遵守元数据约束：`name` 小写 kebab-case、≤64 字符；`description` ≤200 字符且必须包含触发线索（`Use when...`）；`intent` 是更长的面向仓库的摘要（无字符限制）；`type` 是 `component`、`interactive`、`workflow` 之一。
27. 遇到范围蔓延反模式：如果用户想用一个技能覆盖所有产品策略——愿景、路线图、OKR、优先级、干系人对齐和指标——告诉用户这是 4-6 个独立技能，不是 1 个；让用户选当前最紧急的一块，并给出映射：愿景→component，路线图规划→workflow（已有 `roadmap-planning`），优先级→interactive（已有 `prioritization-advisor`），其他→另说；先做一个。
28. 修复 Pitfall 1 类型混淆：当把「带编号步骤的模板」误称为 workflow 时，会导致过度工程、引用不存在的子技能、用户困惑；按 Q2 的类型决策问题诚实判断；如果不编排其他技能、也没有不同输入/输出的明确阶段，那大概率是 component。
29. 修复 Pitfall 2 描述不触发：若描述只说什么（如 `A framework for pricing decisions`）而不说何时用，Claude 无法匹配用户请求，技能会被闲置；每条描述必须回答 `Use when...`，例如 `Evaluate pricing decisions using a structured framework. Use when choosing between pricing models or preparing a pricing proposal.`
30. 修复 Pitfall 3 跳过验证：不要因为「草稿看起来不错，发布吧」就跳过；会造成 frontmatter 损坏、缺失章节、交叉引用失败、目录计数不一致；在认为完成前始终运行 `check-skill-metadata.py` 和 `check-skill-triggers.py`，无例外。
31. 修复 Pitfall 4 大杂烩范围：若试图把整个领域塞进一个技能，会变成 500 行怪物，什么都做不好，太宽无法准确触发，太长无用；一个技能 = 一个工作；如果需要超过 6 个 Application 步骤或超过 4 条分支，可能就需要多个技能。
32. 示例：Framework → Component：Q1 选择框架（build-vs-buy 2x2 矩阵），Q2 确认 component，Q3 命名 `build-vs-buy-matrix`，Q4 提供坐标轴、四象限、质量标准，Q5 提供陷阱；输出完整 component 技能，含模板、填写示例和季度评审陷阱。
33. 示例：Advisory Topic → Interactive：Q1 选择辅导主题（首次与领导层进行定价对话），Q2 确认 interactive，Q3 命名 `pricing-conversation-advisor`，Q4 提供开场问题、分支、建议，Q5 提供失败模式；输出完整 interactive 技能，含 3 问流程、4 个分支和枚举建议。
34. 可参考相关技能：`skill-authoring-workflow`（过程清单和验证门，在本技能生成草稿后使用）；`workshop-facilitation`（本交互技能的引导协议）。
35. 可参考仓库工具：`scripts/build-a-skill.sh`（逐节创建技能的终端向导）；`scripts/add-a-skill.sh`（内容优先的自动生成器）；`scripts/check-skill-metadata.py`（结构校验）；`scripts/check-skill-triggers.py`（触发就绪审计）；`scripts/test-a-skill.sh`（完整质量门）；`scripts/find-a-skill.sh`（创建前检查重叠技能）。
36. 可参考文档：`CLAUDE.md`（主技能蒸馏协议和质量标准）；`docs/Building PM Skills.md`（手动技能创建指南）；`docs/Add-a-Skill Utility Guide.md`（自动创建指南）。

适用边界 · 注意事项

• 范围过大，想一个技能覆盖多个独立领域（如愿景、路线图、OKR、优先级、干系人、指标）时，应先拆分成 4-6 个技能并选一个，不要用本技能硬塞。
• 已经明确要构建什么、只需要流程清单和验证步骤时，不用本技能；改用 `skill-authoring-workflow`。
• 已清楚技能结构、想通过终端向导逐节收集内容，或已有源文档并想端到端 AI 辅助生成时，不用本技能；分别改用 `scripts/build-a-skill.sh` 或 `scripts/add-a-skill.sh`。