[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6J021TWMCCDPCM5X5XC761D":3,"skill-same:01M6J021TWMCCDPCM5X5XC761D":65},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":31,"linkOnly":32,"markdownContent":33,"markdownBody":34,"frontMatter":35,"refName":42,"commitSha":43,"skillDirectory":44,"forksCount":45,"repositoryHtmlUrl":46,"repositoryHomepageUrl":47,"ownerHtmlUrl":48,"ownerBlogUrl":47,"ownerDescription":49,"updatedAt":50,"install":51,"resources":64},"01M6J021TWMCCDPCM5X5XC761D","pm-priority",null,"Use when: 有多个需求需要排定先后顺序、资源有限需决定先做什么、需求冲突需要客观评分\nDo NOT use when: 只有一个需求无需排序、优先级已由上级\u002F业务方明确指定","konglong87\u002FsuperPM","konglong87","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F38234954?v=4","01M6HZZN5EA0572RY1RZAFRKHV","to be a better gopher","01M6HZZN9YN157X26KMMAA147E",91,"MIT","https:\u002F\u002Fgithub.com\u002Fkonglong87\u002FsuperPM\u002Fblob\u002Fmain\u002Fskills\u002F01-demand-insight\u002Fpm-priority\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30],"pm","pm priority","Bash","read","write","use","do","2026-11-10 10:12:30",false,"---\nname: pm-priority\ndescription: |\n  Use when: 有多个需求需要排定先后顺序、资源有限需决定先做什么、需求冲突需要客观评分\n  Do NOT use when: 只有一个需求无需排序、优先级已由上级\u002F业务方明确指定\nallowed-tools:\n  - Read\n  - Write\n  - AskUserQuestion\n  - Agent\n  - Bash\n---\n\n## Preamble (run first)\n\n```bash\n# 检查是否有确认需求清单\nif [ ! -f \"docs\u002F01-需求调研\u002F确认需求清单.md\" ]; then\n  echo \"⚠️  未找到确认需求清单\"\n  echo \"\"\n  echo \"建议先执行 \u002Fpm-clarify 细化需求\"\n  echo \"\"\n  echo \"您可以选择：\"\n  echo \"A) 执行 \u002Fpm-clarify 先细化需求（推荐）\"\n  echo \"B) 手动输入需求列表（快速模式）\"\n  echo \"C) 从需求池导入（执行过 \u002Fpm-pool）\"\nfi\n```\n\n---\n\n## 写入时边界\n\n只讨论时不写文件，启动检查不创建目录。用户要求保存产物时，先确认当前产品、精确输出路径及已有文件的覆盖\u002F追加选择；确认后**仅在实际 Write 前**创建该输出文件的父目录。完整安装可参见 `skills\u002F_shared\u002Fartifact-policy.md`，单独安装本 skill 也按本段执行。\n\n---\n\n## 跨 Agent 交互规则\n\n当流程要求与用户交互时：\n\n1. 如果当前环境支持 AskUserQuestion，使用 AskUserQuestion（最佳体验）。\n2. 如果当前环境不支持 AskUserQuestion，必须用普通聊天消息提出同样问题。\n3. 一次只问一个问题。\n4. 提问后必须停止当前回合，等待用户回答（STOP and WAIT）。\n5. 不得在用户回答前生成文档、写入 docs。\n6. 已有 docs 文件不能替代本轮用户回答。\n\n---\n\n产出要求：每项排序保留需求标识、证据来源及日期、评分依据和置信度；缺失数据标为假设，不以估算冒充事实。将最终取舍及责任人传递给 MVP 方案。\n\n**缺数据的 RICE 门禁**：如果需求只有 A\u002FB\u002FC 之类占位代号，且缺少 Reach（覆盖人数）或 Effort（工作量）估计，不得替 A\u002FB\u002FC 填任何精确数值或计算示例分数；即使写“假设”“仅示例”也会让占位符看起来已有排序。只给空白输入表、公式、待补的数据和一个关键澄清问题，STOP and WAIT。获得各需求含义和同口径的估计后，才可计算或展示标注假设的区间。\n\n## 执行流程\n\n\n### 步骤 1: 读取前置数据（主 agent）\n\n**如果有确认需求清单**：\n\n使用 Read 工具读取 `docs\u002F01-需求调研\u002F确认需求清单.md`\n\n提取需求列表。\n\n**如果有需求调研报告**：\n\n使用 Read 工具读取 `docs\u002F01-需求调研\u002F需求调研报告.md`\n\n提取初步需求列表和背景信息。\n\n**如果有市场调研报告**：\n\n使用 Read 工具读取 `docs\u002F01-需求调研\u002F市场调研报告.md`（如存在）\n\n提取市场数据、竞品信息，为后续评分提供数据支撑。\n\n**如果没有前置文档**：\n\n进入快速模式，使用 AskUserQuestion 收集需求列表。\n\n---\n\n### 步骤 2: 选择排序模型（主 agent - 用户交互）\n\n使用 AskUserQuestion 询问：\n\n> ? 选择需求优先级排序模型：\n>\n> A) RICE评分 - 综合Reach、Impact、Confidence、Effort（推荐）\n> B) KANO模型 - 基于用户满意度分类需求\n> C)  MoSCoW法则 - Must\u002FShould\u002FCould\u002FWon't分类\n> D) 自定义权重 - 自定义评分维度\n\n用户选择后，记录到变量 `PRIORITY_MODEL`\n\n---\n\n### 步骤 3: Subagent 并行预分析（v2.0 核心优化）\n\n**优化说明**：\n- 每个需求派发一个 subagent，读取所有前置文档，基于数据和所选模型生成初始评分建议\n- 多个需求并行分析，总耗时等于单个需求分析时间\n- 预分析结果包含评分 + 数据依据，用户只需确认或微调\n- 大幅减少逐维度询问的交互轮次\n\n---\n\n#### 3.1 构建预分析任务\n\n对每个需求，构建一个 subagent 任务：\n\n```json\n[\n  {\n    \"task_id\": \"prescore_req_1\",\n    \"requirement\": \"{需求1名称}\",\n    \"model\": \"{PRIORITY_MODEL}\",\n    \"docs\": [\"docs\u002F01-需求调研\u002F确认需求清单.md\", \"docs\u002F01-需求调研\u002F需求调研报告.md\"]\n  },\n  {\n    \"task_id\": \"prescore_req_2\",\n    \"requirement\": \"{需求2名称}\",\n    \"model\": \"{PRIORITY_MODEL}\",\n    \"docs\": [\"docs\u002F01-需求调研\u002F确认需求清单.md\", \"docs\u002F01-需求调研\u002F需求调研报告.md\"]\n  }\n]\n```\n\n**如果需求数量 > 10**，提示用户：\n\n> ⚠️ 需求数量较多（{N}个），预分析可能需要较长时间\n>\n> 您可以选择：\n> A) 全部预分析\n> B) 仅对核心需求预分析（前10个）\n> C) 跳过预分析，直接手动评分\n\n---\n\n#### 3.2 并行派发 subagent\n\n同时派发所有 subagent：\n\n```\n# 并行派发 N 个 subagent\nAgent 1: 预分析-{需求1}\nAgent 2: 预分析-{需求2}\n...\nAgent N: 预分析-{需求N}\n```\n\n每个 subagent 的 prompt 模板：\n\n```\nTool: Agent\nParameters:\n  subagent_type: \"general-purpose\"\n  description: \"预分析-{需求名称}\"\n  prompt: |\n    你是一个产品优先级分析专家。请基于前置文档，为指定需求生成评分建议。\n\n    **需求名称**: {需求名称}\n    **排序模型**: {PRIORITY_MODEL}\n    **前置文档路径**:\n    - docs\u002F01-需求调研\u002F确认需求清单.md\n    - docs\u002F01-需求调研\u002F需求调研报告.md\n    - docs\u002F01-需求调研\u002F市场调研报告.md（如存在）\n\n    **任务**：\n    1. 使用 Read 工具读取上述前置文档\n    2. 根据排序模型，分析该需求的评分维度\n    3. 给出每个维度的建议评分和依据\n\n    ---\n\n    #### 如果选择 RICE 评分：\n\n    对指定需求，分析以下 4 个维度：\n\n    **Reach（覆盖人数）**:\n    - 10分: 全部用户\n    - 7分: 大部分用户（50-80%）\n    - 5分: 部分用户（20-50%）\n    - 3分: 少量用户（\u003C20%）\n\n    **Impact（影响程度）**:\n    - 10分: 极大影响 - 直接影响核心指标\n    - 7分: 较大影响 - 显著提升指标\n    - 5分: 中等影响 - 有一定提升\n    - 3分: 较小影响 - 影响有限\n\n    **Confidence（信心度）**:\n    - 10分: 非常有信心 - 有数据或调研支持\n    - 7分: 较有信心 - 有一定依据\n    - 5分: 中等信心 - 基于假设\n    - 3分: 信心不足 - 猜测或不确定\n\n    **Effort（投入成本）**:\n    - 10分: 很小 - 1-2人天\n    - 8分: 较小 - 3-5人天\n    - 5分: 中等 - 1-2人周\n    - 3分: 较大 - 2-4人周\n    - 1分: 很大 - >1人月\n\n    ---\n\n    #### 如果选择 KANO 模型：\n\n    分析该需求属于哪类：\n    - 基本型需求 - 必须有，没有用户会很不满意\n    - 期望型需求 - 越完善用户越满意\n    - 魅力型需求 - 没有没关系，有了会惊喜\n    - 无差异需求 - 有没有都无所谓\n    - 反向型需求 - 有了反而用户不满\n\n    ---\n\n    #### 如果选择 MoSCoW 法则：\n\n    分析该需求的优先级：\n    - Must have - 必须有，否则产品无法使用\n    - Should have - 应该有，重要但非紧急\n    - Could have - 可以有，锦上添花\n    - Won't have - 本期不做，后续考虑\n\n    ---\n\n    #### 如果选择自定义权重：\n\n    分析该需求在以下维度的表现（1-10分）：\n    - 用户价值\n    - 商业价值\n    - 技术可行性\n    - 战略契合度\n\n    ---\n\n    **输出格式**（JSON）：\n    ```json\n    {\n      \"requirement\": \"{需求名称}\",\n      \"model\": \"{PRIORITY_MODEL}\",\n      \"scores\": {\n        \"reach\": {\"score\": 7, \"reasoning\": \"依据文档中的用户规模数据...\"},\n        \"impact\": {\"score\": 8, \"reasoning\": \"该需求直接解决文档中提到的核心痛点...\"},\n        \"confidence\": {\"score\": 7, \"reasoning\": \"市场调研报告中有相关数据支撑...\"},\n        \"effort\": {\"score\": 5, \"reasoning\": \"基于需求复杂度评估...\"}\n      },\n      \"rice_score\": \"（自动计算: Reach × Impact × Confidence \u002F Effort）\",\n      \"key_evidence\": [\"支撑依据1\", \"支撑依据2\"],\n      \"risk_flag\": \"如有数据矛盾或不确定性，在此标注\"\n    }\n    ```\n\n    **重要**：\n    - 评分必须有前置文档中的数据支撑，不能凭空猜测\n    - 如果文档中没有足够信息，在 risk_flag 中标明不确定性\n    - 用中文返回 reasoning 和 key_evidence\n```\n\n**主 agent 等待所有 subagent 完成**，收集 JSON 结果。\n\n---\n\n### 步骤 4: 用户确认\u002F调整评分（主 agent）\n\n主 agent 汇总所有 subagent 的预分析结果，以表格形式展示：\n\n```markdown\n## ? 预分析评分结果（{PRIORITY_MODEL}）\n\n| 需求 | Reach | Impact | Confidence | Effort | RICE得分 | 预分级 |\n|------|-------|--------|------------|--------|----------|--------|\n| {需求1} | 7 | 8 | 7 | 5 | 78.4 | P0 |\n| {需求2} | 5 | 7 | 6 | 8 | 26.3 | P1 |\n| {需求3} | 3 | 5 | 5 | 3 | 25.0 | P2 |\n\n**关键依据**：\n- {需求1}：{subagent 返回的 key_evidence}\n- {需求2}：{subagent 返回的 key_evidence}\n\n**风险提示**：\n- {如有 risk_flag，在此展示}\n```\n\n使用 AskUserQuestion 逐需求确认：\n\n> ? 确认\"{需求名称}\"的评分：\n>\n> 当前预评分：Reach={R} Impact={I} Confidence={C} Effort={E} → RICE={得分}\n>\n> A) 确认，无需调整\n> B) 调整 Reach\n> C) 调整 Impact\n> D) 调整 Confidence\n> E) 调整 Effort\n> F) 重新评估此需求\n>\n> ? 依据：{subagent key_evidence}\n\n**快速确认模式**（需求数量 ≤ 5）：\n\n> ✅ 以上预评分结果是否认可？\n>\n> A) 全部确认，直接生成报告（推荐）\n> B) 逐个调整\n> C) 全部重新评估\n\n---\n\n### 步骤 5: Subagent 生成优先级排序报告（v2.0 优化）\n\n**优化说明**：报告生成交给 subagent，主 agent 上下文保持清爽\n\n使用 Agent 工具派发 subagent 生成报告：\n\n```\nTool: Agent\nParameters:\n  subagent_type: \"general-purpose\"\n  description: \"生成优先级排序报告\"\n  prompt: |\n    你是一个产品文档专家。请根据以下数据生成优先级排序报告。\n\n    **排序模型**: {PRIORITY_MODEL}\n    **需求评分数据**:\n    ```json\n    {所有需求的最终评分 JSON}\n    ```\n\n    **报告要求**：\n    1. 使用 Write 工具保存到 `docs\u002F01-需求调研\u002F优先级排序报告.md`\n    2. 严格按照以下模板格式\n    3. P0\u002FP1\u002FP2\u002FP3 分级规则：\n       - P0: RICE ≥ 50 或 Must have \u002F 基本型\n       - P1: RICE 20-49 或 Should have \u002F 期望型\n       - P2: RICE 5-19 或 Could have \u002F 魅力型\n       - P3: RICE \u003C 5 或 Won't have \u002F 无差异\u002F反向型\n\n    **报告模板**：\n\n    ```markdown\n    # 优先级排序报告\n\n    ## 一、基础信息\n\n    - **排序模型**: {PRIORITY_MODEL}\n    - **需求数量**: {N}个\n    - **生成时间**: {当前时间}\n\n    ---\n\n    ## 二、排序结果\n\n    ### 2.1 需求优先级列表\n\n    | 排名 | 需求名称 | {模型对应列头} | 优先级 |\n    |------|----------|{列头}|--------|\n    | 1 | {需求1} | {得分} | P0 |\n    | 2 | {需求2} | {得分} | P0 |\n    | 3 | {需求3} | {得分} | P1 |\n    | ... | ... | ... | ... |\n\n    ### 2.2 优先级分组\n\n    **P0 - 核心需求（必须做）**:\n    1. {需求1} - {得分详情}\n    2. {需求2} - {得分详情}\n\n    **P1 - 重要需求（应该做）**:\n    1. {需求3} - {得分详情}\n\n    **P2 - 次要需求（可以做）**:\n    1. {需求4} - {得分详情}\n\n    **P3 - 待定需求（暂缓）**:\n    1. {需求5} - {得分详情}\n\n    ---\n\n    ## 三、评分详情\n\n    逐需求展开评分依据：\n\n    ### {需求1}\n\n    | 维度 | 评分 | 依据 |\n    |------|------|------|\n    | Reach | {R} | {reasoning} |\n    | Impact | {I} | {reasoning} |\n    | Confidence | {C} | {reasoning} |\n    | Effort | {E} | {reasoning} |\n    | **RICE** | **{得分}** | = {R}×{I}×{C}\u002F{E} |\n\n    ...\n\n    ---\n\n    ## 四、排序依据\n\n    ### {模型评分说明}\n\n    （根据实际使用的模型展开评分规则说明）\n\n    ---\n\n    ## 五、实施建议\n\n    ### 5.1 MVP范围建议\n\n    建议第一版（MVP）包含 P0 级需求，共 {N} 个需求：\n\n    1. {需求1}\n    2. {需求2}\n    ...\n\n    预计工作量: {估算}\n\n    ### 5.2 后续迭代\n\n    **第二版（V1.1）**: P1级需求\n    **第三版（V1.2）**: P2级需求\n\n    ---\n\n    ## 六、下一步建议\n\n    建议执行：\n\n    1. **\u002Fpm-mvp** - MVP规划，确定第一版具体方案（推荐）\n    2. **\u002Fpm-docs** - 生成PRD文档\n    3. **\u002Fpm-pool** - 需求池管理，长期跟踪需求\n\n    ---\n\n    **项目状态**: 优先级排序完成\n    **生成时间**: {时间戳}\n    **生成工具**: super-pm\n    ```\n\n    **注意**：\n    - 如果模型是 KANO 或 MoSCoW，调整列头和评分显示格式\n    - 评分依据来自步骤3 subagent 返回的 reasoning\n    - 确保 Markdown 格式正确、表格对齐\n```\n\n**主 agent 等待 subagent 完成报告生成**。\n\n---\n\n### 步骤 6: 输出完成提示（主 agent）\n\n使用 AskUserQuestion 提供下一步选项：\n\n> ✅ 优先级排序完成！\n>\n> ? 优先级排序报告已生成：`docs\u002F01-需求调研\u002F优先级排序报告.md`\n>\n> ? 建议下一步：\n>\n> A) 执行 \u002Fpm-mvp - MVP规划，确定第一版方案（推荐）\n> B) 执行 \u002Fpm-docs - 生成PRD文档\n> C) 执行 \u002Fpm-pool - 需求池管理\n> D) 查看优先级排序报告\n\n---\n\n## 对比：优化前 vs 优化后\n\n### 优化前（pm-priority v1.1.0）\n\n```\n主 agent 执行流程：\n1. 读取前置数据（50 tokens）\n2. 询问排序模型（10 tokens）\n3. 对需求1逐维度询问（4轮交互，每轮 ~200 tokens）\n4. 对需求2逐维度询问（4轮交互，每轮 ~200 tokens）\n5. 对需求N逐维度询问...\n6. 汇总计算（50 tokens）\n7. 生成报告（~800 tokens 写入）\n\n总计（以5个需求为例）：\n- 交互轮次：1 + 1 + 5×4 = 22 轮\n- 上下文消耗：~5,000 tokens（报告模板占用大头）\n- 耗时：约 5-8 分钟（串行交互）\n```\n\n### 优化后（pm-priority v2.0.0）\n\n```\n主 agent 执行流程：\n1. 读取前置数据（50 tokens）\n2. 询问排序模型（10 tokens）\n3. 并行派发 subagent 预分析（20 tokens × N个任务）\n   └─ 每个 Subagent 读取文档 + 分析（不占用主 agent 上下文）\n4. 展示预评分 + 确认（200 tokens，1-2轮交互）\n5. 派发 subagent 生成报告（20 tokens）\n   └─ Subagent 生成报告（不占用主 agent 上下文）\n6. 输出完成提示（10 tokens）\n\n总计（以5个需求为例）：\n- 交互轮次：1 + 1 + 1-2 + 1 = 4-5 轮\n- 主 agent 上下文消耗：~400 tokens（减少 90%+）\n- 耗时：约 1.5-3 分钟（并行分析 + 快速确认）\n- 效率提升：4x 交互减少，5x+ token 节省\n```\n\n### Token 使用对比\n\n| 指标 | v1.1.0 | v2.0.0 | 改善 |\n|------|--------|--------|------|\n| 主 agent token | ~5,000 | ~400 | -92% |\n| Subagent token | 0 | ~2,500 | N\u002FA |\n| 交互轮次 | 22 | 4-5 | -80% |\n| 总耗时 | 5-8 min | 1.5-3 min | 2.5-3x |\n\n---\n\n## 关键优化点\n\n### 1. 上下文节省\n- ✅ 逐维度评分对话不占用主 agent 上下文\n- ✅ 报告生成模板不占用主 agent 上下文\n- ✅ 主 agent 只处理结构化评分数据\n- ✅ Token 使用减少 90%+\n\n### 2. 执行效率\n- ✅ 多个需求并行预分析\n- ✅ 用户只需确认而非逐维度回答\n- ✅ 交互轮次从 22 轮降至 4-5 轮\n- ✅ 总耗时减少 60-70%\n\n### 3. 评分质量\n- ✅ 预分析基于前置文档数据，减少主观猜测\n- ✅ 每个评分都有明确依据（key_evidence）\n- ✅ 数据不确定性在 risk_flag 中标注\n- ✅ 用户保留最终决策权\n\n---\n\n## 兜底机制\n\n### 场景 1: 无需求清单\n\n提供快速模式，允许手动输入需求列表。\n\n### 场景 2: 需求数量过多\n\n如果需求数量 > 15，询问用户：\n\n> ⚠️ 需求数量较多（{N}个），评分可能需要较长时间\n>\n> 您可以选择：\n> A) 全部评分\n> B) 仅对核心需求评分（前10个）\n> C) 我来选择要评分的需求\n\n### 场景 3: Subagent 预分析失败\n\n如果某个 subagent 执行失败：\n\n1. 主 agent 检测到错误\n2. 标记该需求为\"需手动评分\"\n3. 对其余需求继续确认流程\n4. 对失败的需求，降级为手动逐维度询问\n\n### 场景 4: 无前置文档（快速模式）\n\n如果无前置文档可供 subagent 分析：\n\n1. 跳过步骤 3（预分析）\n2. 直接进入手动评分模式（原 v1.1.0 流程）\n3. 仍然使用 subagent 生成报告（步骤 5）\n\n---\n\n## 异常处理\n\n如果 subagent 执行失败：\n1. 主 agent 检测到错误\n2. 提供降级方案：手动逐需求评分（原 v1.1.0 模式）\n3. 记录错误信息供用户排查\n\n---\n\n## 版本说明\n\n**v2.0.0** - Subagent 架构重构\n- 新增 Agent 工具支持\n- 需求预分析并行化（Subagent 读取文档 + 评分建议）\n- 报告生成 Subagent 化\n- 交互轮次减少 80%\n- Token 节省 90%+\n- 评分增加数据依据追溯\n\n**v1.1.0** - 功能增强\n- 新增自定义权重评分模型\n- 需求数量 > 15 的分批处理\n\n**v1.0.0** - 初始版本\n- RICE\u002FKANO\u002FMoSCoW 三种排序模型\n- 逐需求交互评分\n- 优先级排序报告生成\n\n---\n\n## 注意事项\n\n1. **一次一个需求确认**：避免用户负担过重\n2. **评分标准明确**：每个选项对应明确分数\n3. **RICE计算自动**：AI自动计算得分\n4. **优先级分组**：P0\u002FP1\u002FP2\u002FP3便于后续决策\n5. **Markdown存储**：排序报告人类可读可编辑\n6. **Subagent 预分析**：基于文档数据的评分建议，用户拥有最终决定权\n\n---\n\n## 输出质量对比\n\n**✅ Good 示例**：\n```\n- 有数据引用：「根据 Q4 数据，留存率从 35% 降至 28%」\n- 有验证来源：「数据来源：Google Analytics, 2025-12-01」\n- 有明确建议：「建议将新手引导步骤从 5 步减少至 3 步」\n```\n\n**❌ Bad 示例**：\n```\n- 模糊结论：「数据表明留存率有所下降」\n- 无来源：「根据经验，这个功能很重要」\n- 没有行动建议：「留存是个问题」\n```\n\n---\n\n## 常见误区 \u002F Red Flags — STOP\n\n出现以下情况立即停止并回溯：\n\n| 误区 | 正确做法 |\n|------|---------|\n| 使用\"应该\"、\"大概\"、\"看起来\"做结论 | 必须基于实际数据和验证 |\n| 未运行检查就声称已完成 | 先验证，再陈述 |\n| 因时间紧迫跳过关键步骤 | 没有例外，时间紧更要严格 |\n| \"这次应该没问题\"的想法 | 每次都要重新验证 |\n\n---\n\n## 产出质量检查 \u002F Verification Checklist\n\n- [ ] 前置依赖已满足（输入文档\u002F数据已收集）\n- [ ] 核心步骤已全部执行\n- [ ] 输出文档已生成到 `docs\u002F` 目录\n- [ ] 每个评分都有数据\u002F证据支撑\n- [ ] 已推荐 2-3 个后续 skill\n\n> ⚠️ 任何一项未通过 → 补全后再标记完成。\n\n---\n","## Preamble (run first)\n\n```bash\n# 检查是否有确认需求清单\nif [ ! -f \"docs\u002F01-需求调研\u002F确认需求清单.md\" ]; then\n  echo \"⚠️  未找到确认需求清单\"\n  echo \"\"\n  echo \"建议先执行 \u002Fpm-clarify 细化需求\"\n  echo \"\"\n  echo \"您可以选择：\"\n  echo \"A) 执行 \u002Fpm-clarify 先细化需求（推荐）\"\n  echo \"B) 手动输入需求列表（快速模式）\"\n  echo \"C) 从需求池导入（执行过 \u002Fpm-pool）\"\nfi\n```\n\n---\n\n## 写入时边界\n\n只讨论时不写文件，启动检查不创建目录。用户要求保存产物时，先确认当前产品、精确输出路径及已有文件的覆盖\u002F追加选择；确认后**仅在实际 Write 前**创建该输出文件的父目录。完整安装可参见 `skills\u002F_shared\u002Fartifact-policy.md`，单独安装本 skill 也按本段执行。\n\n---\n\n## 跨 Agent 交互规则\n\n当流程要求与用户交互时：\n\n1. 如果当前环境支持 AskUserQuestion，使用 AskUserQuestion（最佳体验）。\n2. 如果当前环境不支持 AskUserQuestion，必须用普通聊天消息提出同样问题。\n3. 一次只问一个问题。\n4. 提问后必须停止当前回合，等待用户回答（STOP and WAIT）。\n5. 不得在用户回答前生成文档、写入 docs。\n6. 已有 docs 文件不能替代本轮用户回答。\n\n---\n\n产出要求：每项排序保留需求标识、证据来源及日期、评分依据和置信度；缺失数据标为假设，不以估算冒充事实。将最终取舍及责任人传递给 MVP 方案。\n\n**缺数据的 RICE 门禁**：如果需求只有 A\u002FB\u002FC 之类占位代号，且缺少 Reach（覆盖人数）或 Effort（工作量）估计，不得替 A\u002FB\u002FC 填任何精确数值或计算示例分数；即使写“假设”“仅示例”也会让占位符看起来已有排序。只给空白输入表、公式、待补的数据和一个关键澄清问题，STOP and WAIT。获得各需求含义和同口径的估计后，才可计算或展示标注假设的区间。\n\n## 执行流程\n\n\n### 步骤 1: 读取前置数据（主 agent）\n\n**如果有确认需求清单**：\n\n使用 Read 工具读取 `docs\u002F01-需求调研\u002F确认需求清单.md`\n\n提取需求列表。\n\n**如果有需求调研报告**：\n\n使用 Read 工具读取 `docs\u002F01-需求调研\u002F需求调研报告.md`\n\n提取初步需求列表和背景信息。\n\n**如果有市场调研报告**：\n\n使用 Read 工具读取 `docs\u002F01-需求调研\u002F市场调研报告.md`（如存在）\n\n提取市场数据、竞品信息，为后续评分提供数据支撑。\n\n**如果没有前置文档**：\n\n进入快速模式，使用 AskUserQuestion 收集需求列表。\n\n---\n\n### 步骤 2: 选择排序模型（主 agent - 用户交互）\n\n使用 AskUserQuestion 询问：\n\n> ? 选择需求优先级排序模型：\n>\n> A) RICE评分 - 综合Reach、Impact、Confidence、Effort（推荐）\n> B) KANO模型 - 基于用户满意度分类需求\n> C)  MoSCoW法则 - Must\u002FShould\u002FCould\u002FWon't分类\n> D) 自定义权重 - 自定义评分维度\n\n用户选择后，记录到变量 `PRIORITY_MODEL`\n\n---\n\n### 步骤 3: Subagent 并行预分析（v2.0 核心优化）\n\n**优化说明**：\n- 每个需求派发一个 subagent，读取所有前置文档，基于数据和所选模型生成初始评分建议\n- 多个需求并行分析，总耗时等于单个需求分析时间\n- 预分析结果包含评分 + 数据依据，用户只需确认或微调\n- 大幅减少逐维度询问的交互轮次\n\n---\n\n#### 3.1 构建预分析任务\n\n对每个需求，构建一个 subagent 任务：\n\n```json\n[\n  {\n    \"task_id\": \"prescore_req_1\",\n    \"requirement\": \"{需求1名称}\",\n    \"model\": \"{PRIORITY_MODEL}\",\n    \"docs\": [\"docs\u002F01-需求调研\u002F确认需求清单.md\", \"docs\u002F01-需求调研\u002F需求调研报告.md\"]\n  },\n  {\n    \"task_id\": \"prescore_req_2\",\n    \"requirement\": \"{需求2名称}\",\n    \"model\": \"{PRIORITY_MODEL}\",\n    \"docs\": [\"docs\u002F01-需求调研\u002F确认需求清单.md\", \"docs\u002F01-需求调研\u002F需求调研报告.md\"]\n  }\n]\n```\n\n**如果需求数量 > 10**，提示用户：\n\n> ⚠️ 需求数量较多（{N}个），预分析可能需要较长时间\n>\n> 您可以选择：\n> A) 全部预分析\n> B) 仅对核心需求预分析（前10个）\n> C) 跳过预分析，直接手动评分\n\n---\n\n#### 3.2 并行派发 subagent\n\n同时派发所有 subagent：\n\n```\n# 并行派发 N 个 subagent\nAgent 1: 预分析-{需求1}\nAgent 2: 预分析-{需求2}\n...\nAgent N: 预分析-{需求N}\n```\n\n每个 subagent 的 prompt 模板：\n\n```\nTool: Agent\nParameters:\n  subagent_type: \"general-purpose\"\n  description: \"预分析-{需求名称}\"\n  prompt: |\n    你是一个产品优先级分析专家。请基于前置文档，为指定需求生成评分建议。\n\n    **需求名称**: {需求名称}\n    **排序模型**: {PRIORITY_MODEL}\n    **前置文档路径**:\n    - docs\u002F01-需求调研\u002F确认需求清单.md\n    - docs\u002F01-需求调研\u002F需求调研报告.md\n    - docs\u002F01-需求调研\u002F市场调研报告.md（如存在）\n\n    **任务**：\n    1. 使用 Read 工具读取上述前置文档\n    2. 根据排序模型，分析该需求的评分维度\n    3. 给出每个维度的建议评分和依据\n\n    ---\n\n    #### 如果选择 RICE 评分：\n\n    对指定需求，分析以下 4 个维度：\n\n    **Reach（覆盖人数）**:\n    - 10分: 全部用户\n    - 7分: 大部分用户（50-80%）\n    - 5分: 部分用户（20-50%）\n    - 3分: 少量用户（\u003C20%）\n\n    **Impact（影响程度）**:\n    - 10分: 极大影响 - 直接影响核心指标\n    - 7分: 较大影响 - 显著提升指标\n    - 5分: 中等影响 - 有一定提升\n    - 3分: 较小影响 - 影响有限\n\n    **Confidence（信心度）**:\n    - 10分: 非常有信心 - 有数据或调研支持\n    - 7分: 较有信心 - 有一定依据\n    - 5分: 中等信心 - 基于假设\n    - 3分: 信心不足 - 猜测或不确定\n\n    **Effort（投入成本）**:\n    - 10分: 很小 - 1-2人天\n    - 8分: 较小 - 3-5人天\n    - 5分: 中等 - 1-2人周\n    - 3分: 较大 - 2-4人周\n    - 1分: 很大 - >1人月\n\n    ---\n\n    #### 如果选择 KANO 模型：\n\n    分析该需求属于哪类：\n    - 基本型需求 - 必须有，没有用户会很不满意\n    - 期望型需求 - 越完善用户越满意\n    - 魅力型需求 - 没有没关系，有了会惊喜\n    - 无差异需求 - 有没有都无所谓\n    - 反向型需求 - 有了反而用户不满\n\n    ---\n\n    #### 如果选择 MoSCoW 法则：\n\n    分析该需求的优先级：\n    - Must have - 必须有，否则产品无法使用\n    - Should have - 应该有，重要但非紧急\n    - Could have - 可以有，锦上添花\n    - Won't have - 本期不做，后续考虑\n\n    ---\n\n    #### 如果选择自定义权重：\n\n    分析该需求在以下维度的表现（1-10分）：\n    - 用户价值\n    - 商业价值\n    - 技术可行性\n    - 战略契合度\n\n    ---\n\n    **输出格式**（JSON）：\n    ```json\n    {\n      \"requirement\": \"{需求名称}\",\n      \"model\": \"{PRIORITY_MODEL}\",\n      \"scores\": {\n        \"reach\": {\"score\": 7, \"reasoning\": \"依据文档中的用户规模数据...\"},\n        \"impact\": {\"score\": 8, \"reasoning\": \"该需求直接解决文档中提到的核心痛点...\"},\n        \"confidence\": {\"score\": 7, \"reasoning\": \"市场调研报告中有相关数据支撑...\"},\n        \"effort\": {\"score\": 5, \"reasoning\": \"基于需求复杂度评估...\"}\n      },\n      \"rice_score\": \"（自动计算: Reach × Impact × Confidence \u002F Effort）\",\n      \"key_evidence\": [\"支撑依据1\", \"支撑依据2\"],\n      \"risk_flag\": \"如有数据矛盾或不确定性，在此标注\"\n    }\n    ```\n\n    **重要**：\n    - 评分必须有前置文档中的数据支撑，不能凭空猜测\n    - 如果文档中没有足够信息，在 risk_flag 中标明不确定性\n    - 用中文返回 reasoning 和 key_evidence\n```\n\n**主 agent 等待所有 subagent 完成**，收集 JSON 结果。\n\n---\n\n### 步骤 4: 用户确认\u002F调整评分（主 agent）\n\n主 agent 汇总所有 subagent 的预分析结果，以表格形式展示：\n\n```markdown\n## ? 预分析评分结果（{PRIORITY_MODEL}）\n\n| 需求 | Reach | Impact | Confidence | Effort | RICE得分 | 预分级 |\n|------|-------|--------|------------|--------|----------|--------|\n| {需求1} | 7 | 8 | 7 | 5 | 78.4 | P0 |\n| {需求2} | 5 | 7 | 6 | 8 | 26.3 | P1 |\n| {需求3} | 3 | 5 | 5 | 3 | 25.0 | P2 |\n\n**关键依据**：\n- {需求1}：{subagent 返回的 key_evidence}\n- {需求2}：{subagent 返回的 key_evidence}\n\n**风险提示**：\n- {如有 risk_flag，在此展示}\n```\n\n使用 AskUserQuestion 逐需求确认：\n\n> ? 确认\"{需求名称}\"的评分：\n>\n> 当前预评分：Reach={R} Impact={I} Confidence={C} Effort={E} → RICE={得分}\n>\n> A) 确认，无需调整\n> B) 调整 Reach\n> C) 调整 Impact\n> D) 调整 Confidence\n> E) 调整 Effort\n> F) 重新评估此需求\n>\n> ? 依据：{subagent key_evidence}\n\n**快速确认模式**（需求数量 ≤ 5）：\n\n> ✅ 以上预评分结果是否认可？\n>\n> A) 全部确认，直接生成报告（推荐）\n> B) 逐个调整\n> C) 全部重新评估\n\n---\n\n### 步骤 5: Subagent 生成优先级排序报告（v2.0 优化）\n\n**优化说明**：报告生成交给 subagent，主 agent 上下文保持清爽\n\n使用 Agent 工具派发 subagent 生成报告：\n\n```\nTool: Agent\nParameters:\n  subagent_type: \"general-purpose\"\n  description: \"生成优先级排序报告\"\n  prompt: |\n    你是一个产品文档专家。请根据以下数据生成优先级排序报告。\n\n    **排序模型**: {PRIORITY_MODEL}\n    **需求评分数据**:\n    ```json\n    {所有需求的最终评分 JSON}\n    ```\n\n    **报告要求**：\n    1. 使用 Write 工具保存到 `docs\u002F01-需求调研\u002F优先级排序报告.md`\n    2. 严格按照以下模板格式\n    3. P0\u002FP1\u002FP2\u002FP3 分级规则：\n       - P0: RICE ≥ 50 或 Must have \u002F 基本型\n       - P1: RICE 20-49 或 Should have \u002F 期望型\n       - P2: RICE 5-19 或 Could have \u002F 魅力型\n       - P3: RICE \u003C 5 或 Won't have \u002F 无差异\u002F反向型\n\n    **报告模板**：\n\n    ```markdown\n    # 优先级排序报告\n\n    ## 一、基础信息\n\n    - **排序模型**: {PRIORITY_MODEL}\n    - **需求数量**: {N}个\n    - **生成时间**: {当前时间}\n\n    ---\n\n    ## 二、排序结果\n\n    ### 2.1 需求优先级列表\n\n    | 排名 | 需求名称 | {模型对应列头} | 优先级 |\n    |------|----------|{列头}|--------|\n    | 1 | {需求1} | {得分} | P0 |\n    | 2 | {需求2} | {得分} | P0 |\n    | 3 | {需求3} | {得分} | P1 |\n    | ... | ... | ... | ... |\n\n    ### 2.2 优先级分组\n\n    **P0 - 核心需求（必须做）**:\n    1. {需求1} - {得分详情}\n    2. {需求2} - {得分详情}\n\n    **P1 - 重要需求（应该做）**:\n    1. {需求3} - {得分详情}\n\n    **P2 - 次要需求（可以做）**:\n    1. {需求4} - {得分详情}\n\n    **P3 - 待定需求（暂缓）**:\n    1. {需求5} - {得分详情}\n\n    ---\n\n    ## 三、评分详情\n\n    逐需求展开评分依据：\n\n    ### {需求1}\n\n    | 维度 | 评分 | 依据 |\n    |------|------|------|\n    | Reach | {R} | {reasoning} |\n    | Impact | {I} | {reasoning} |\n    | Confidence | {C} | {reasoning} |\n    | Effort | {E} | {reasoning} |\n    | **RICE** | **{得分}** | = {R}×{I}×{C}\u002F{E} |\n\n    ...\n\n    ---\n\n    ## 四、排序依据\n\n    ### {模型评分说明}\n\n    （根据实际使用的模型展开评分规则说明）\n\n    ---\n\n    ## 五、实施建议\n\n    ### 5.1 MVP范围建议\n\n    建议第一版（MVP）包含 P0 级需求，共 {N} 个需求：\n\n    1. {需求1}\n    2. {需求2}\n    ...\n\n    预计工作量: {估算}\n\n    ### 5.2 后续迭代\n\n    **第二版（V1.1）**: P1级需求\n    **第三版（V1.2）**: P2级需求\n\n    ---\n\n    ## 六、下一步建议\n\n    建议执行：\n\n    1. **\u002Fpm-mvp** - MVP规划，确定第一版具体方案（推荐）\n    2. **\u002Fpm-docs** - 生成PRD文档\n    3. **\u002Fpm-pool** - 需求池管理，长期跟踪需求\n\n    ---\n\n    **项目状态**: 优先级排序完成\n    **生成时间**: {时间戳}\n    **生成工具**: super-pm\n    ```\n\n    **注意**：\n    - 如果模型是 KANO 或 MoSCoW，调整列头和评分显示格式\n    - 评分依据来自步骤3 subagent 返回的 reasoning\n    - 确保 Markdown 格式正确、表格对齐\n```\n\n**主 agent 等待 subagent 完成报告生成**。\n\n---\n\n### 步骤 6: 输出完成提示（主 agent）\n\n使用 AskUserQuestion 提供下一步选项：\n\n> ✅ 优先级排序完成！\n>\n> ? 优先级排序报告已生成：`docs\u002F01-需求调研\u002F优先级排序报告.md`\n>\n> ? 建议下一步：\n>\n> A) 执行 \u002Fpm-mvp - MVP规划，确定第一版方案（推荐）\n> B) 执行 \u002Fpm-docs - 生成PRD文档\n> C) 执行 \u002Fpm-pool - 需求池管理\n> D) 查看优先级排序报告\n\n---\n\n## 对比：优化前 vs 优化后\n\n### 优化前（pm-priority v1.1.0）\n\n```\n主 agent 执行流程：\n1. 读取前置数据（50 tokens）\n2. 询问排序模型（10 tokens）\n3. 对需求1逐维度询问（4轮交互，每轮 ~200 tokens）\n4. 对需求2逐维度询问（4轮交互，每轮 ~200 tokens）\n5. 对需求N逐维度询问...\n6. 汇总计算（50 tokens）\n7. 生成报告（~800 tokens 写入）\n\n总计（以5个需求为例）：\n- 交互轮次：1 + 1 + 5×4 = 22 轮\n- 上下文消耗：~5,000 tokens（报告模板占用大头）\n- 耗时：约 5-8 分钟（串行交互）\n```\n\n### 优化后（pm-priority v2.0.0）\n\n```\n主 agent 执行流程：\n1. 读取前置数据（50 tokens）\n2. 询问排序模型（10 tokens）\n3. 并行派发 subagent 预分析（20 tokens × N个任务）\n   └─ 每个 Subagent 读取文档 + 分析（不占用主 agent 上下文）\n4. 展示预评分 + 确认（200 tokens，1-2轮交互）\n5. 派发 subagent 生成报告（20 tokens）\n   └─ Subagent 生成报告（不占用主 agent 上下文）\n6. 输出完成提示（10 tokens）\n\n总计（以5个需求为例）：\n- 交互轮次：1 + 1 + 1-2 + 1 = 4-5 轮\n- 主 agent 上下文消耗：~400 tokens（减少 90%+）\n- 耗时：约 1.5-3 分钟（并行分析 + 快速确认）\n- 效率提升：4x 交互减少，5x+ token 节省\n```\n\n### Token 使用对比\n\n| 指标 | v1.1.0 | v2.0.0 | 改善 |\n|------|--------|--------|------|\n| 主 agent token | ~5,000 | ~400 | -92% |\n| Subagent token | 0 | ~2,500 | N\u002FA |\n| 交互轮次 | 22 | 4-5 | -80% |\n| 总耗时 | 5-8 min | 1.5-3 min | 2.5-3x |\n\n---\n\n## 关键优化点\n\n### 1. 上下文节省\n- ✅ 逐维度评分对话不占用主 agent 上下文\n- ✅ 报告生成模板不占用主 agent 上下文\n- ✅ 主 agent 只处理结构化评分数据\n- ✅ Token 使用减少 90%+\n\n### 2. 执行效率\n- ✅ 多个需求并行预分析\n- ✅ 用户只需确认而非逐维度回答\n- ✅ 交互轮次从 22 轮降至 4-5 轮\n- ✅ 总耗时减少 60-70%\n\n### 3. 评分质量\n- ✅ 预分析基于前置文档数据，减少主观猜测\n- ✅ 每个评分都有明确依据（key_evidence）\n- ✅ 数据不确定性在 risk_flag 中标注\n- ✅ 用户保留最终决策权\n\n---\n\n## 兜底机制\n\n### 场景 1: 无需求清单\n\n提供快速模式，允许手动输入需求列表。\n\n### 场景 2: 需求数量过多\n\n如果需求数量 > 15，询问用户：\n\n> ⚠️ 需求数量较多（{N}个），评分可能需要较长时间\n>\n> 您可以选择：\n> A) 全部评分\n> B) 仅对核心需求评分（前10个）\n> C) 我来选择要评分的需求\n\n### 场景 3: Subagent 预分析失败\n\n如果某个 subagent 执行失败：\n\n1. 主 agent 检测到错误\n2. 标记该需求为\"需手动评分\"\n3. 对其余需求继续确认流程\n4. 对失败的需求，降级为手动逐维度询问\n\n### 场景 4: 无前置文档（快速模式）\n\n如果无前置文档可供 subagent 分析：\n\n1. 跳过步骤 3（预分析）\n2. 直接进入手动评分模式（原 v1.1.0 流程）\n3. 仍然使用 subagent 生成报告（步骤 5）\n\n---\n\n## 异常处理\n\n如果 subagent 执行失败：\n1. 主 agent 检测到错误\n2. 提供降级方案：手动逐需求评分（原 v1.1.0 模式）\n3. 记录错误信息供用户排查\n\n---\n\n## 版本说明\n\n**v2.0.0** - Subagent 架构重构\n- 新增 Agent 工具支持\n- 需求预分析并行化（Subagent 读取文档 + 评分建议）\n- 报告生成 Subagent 化\n- 交互轮次减少 80%\n- Token 节省 90%+\n- 评分增加数据依据追溯\n\n**v1.1.0** - 功能增强\n- 新增自定义权重评分模型\n- 需求数量 > 15 的分批处理\n\n**v1.0.0** - 初始版本\n- RICE\u002FKANO\u002FMoSCoW 三种排序模型\n- 逐需求交互评分\n- 优先级排序报告生成\n\n---\n\n## 注意事项\n\n1. **一次一个需求确认**：避免用户负担过重\n2. **评分标准明确**：每个选项对应明确分数\n3. **RICE计算自动**：AI自动计算得分\n4. **优先级分组**：P0\u002FP1\u002FP2\u002FP3便于后续决策\n5. **Markdown存储**：排序报告人类可读可编辑\n6. **Subagent 预分析**：基于文档数据的评分建议，用户拥有最终决定权\n\n---\n\n## 输出质量对比\n\n**✅ Good 示例**：\n```\n- 有数据引用：「根据 Q4 数据，留存率从 35% 降至 28%」\n- 有验证来源：「数据来源：Google Analytics, 2025-12-01」\n- 有明确建议：「建议将新手引导步骤从 5 步减少至 3 步」\n```\n\n**❌ Bad 示例**：\n```\n- 模糊结论：「数据表明留存率有所下降」\n- 无来源：「根据经验，这个功能很重要」\n- 没有行动建议：「留存是个问题」\n```\n\n---\n\n## 常见误区 \u002F Red Flags — STOP\n\n出现以下情况立即停止并回溯：\n\n| 误区 | 正确做法 |\n|------|---------|\n| 使用\"应该\"、\"大概\"、\"看起来\"做结论 | 必须基于实际数据和验证 |\n| 未运行检查就声称已完成 | 先验证，再陈述 |\n| 因时间紧迫跳过关键步骤 | 没有例外，时间紧更要严格 |\n| \"这次应该没问题\"的想法 | 每次都要重新验证 |\n\n---\n\n## 产出质量检查 \u002F Verification Checklist\n\n- [ ] 前置依赖已满足（输入文档\u002F数据已收集）\n- [ ] 核心步骤已全部执行\n- [ ] 输出文档已生成到 `docs\u002F` 目录\n- [ ] 每个评分都有数据\u002F证据支撑\n- [ ] 已推荐 2-3 个后续 skill\n\n> ⚠️ 任何一项未通过 → 补全后再标记完成。\n\n---\n",{"name":5,"description":36,"allowed-tools":37},"Use when: 有多个需求需要排定先后顺序、资源有限需决定先做什么、需求冲突需要客观评分\nDo NOT use when: 只有一个需求无需排序、优先级已由上级\u002F业务方明确指定\n",[38,39,40,41,26],"Read","Write","AskUserQuestion","Agent","main","c815a5b055b972b9b56fffce0102dbcf9e8ede7d","skills\u002F01-demand-insight\u002Fpm-priority",8,"https:\u002F\u002Fgithub.com\u002Fkonglong87\u002FsuperPM","https:\u002F\u002Fkonglong87.github.io\u002Fanything-ai\u002F","https:\u002F\u002Fgithub.com\u002Fkonglong87","蓬头稚子学垂纶，侧坐莓苔草映身","2026-10-26 15:12:41",{"source":8,"skillName":5,"commands":52,"prompt":62,"zipAvailable":63},[53,56,59],{"tool":54,"command":55},"npx","npx skills add konglong87\u002FsuperPM --skill pm-priority",{"tool":57,"command":58},"bunx","bunx skills add konglong87\u002FsuperPM --skill pm-priority",{"tool":60,"command":61},"pnpm","pnpm dlx skills add konglong87\u002FsuperPM --skill pm-priority","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fkonglong87\u002FsuperPM\u002Fblob\u002Fmain\u002Fskills\u002F01-demand-insight\u002Fpm-priority\u002FSKILL.md",true,[],[66,95,111,132,145,165],{"skillNo":67,"name":68,"nameZh":6,"description":69,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":70,"categories":71,"keywords":78,"publishedAt":31},"01M6J07VBJZGTH83K1ST4AFTSX","write-prd","PRD writing workflow — chain demand validation, clarification, prioritization, MVP scoping, and document generation\nUse when: Writing a PRD, BRD, or MRD, or need to produce product requirement documents","https:\u002F\u002Fgithub.com\u002Fkonglong87\u002FsuperPM\u002Fblob\u002Fmain\u002Fskills\u002Fworkflows\u002Fwrite-prd\u002FSKILL.md",[72,73],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":74,"categoryName":75,"taxonomyType":76,"taxonomyTypeDesc":77},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",[79,28,80,81,82,83,84,85,86,87,26,27,29,88,89,90,91,92,93,94],"prd","write prd","writing","workflow","documents","validation","product","produce","prioritization","prd writing","document","generation","chain","mvp","document generation","websearch",{"skillNo":96,"name":97,"nameZh":6,"description":98,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":99,"categories":100,"keywords":102,"publishedAt":31},"01M6J07NR1TC4FGKQN2596F8BH","validate-idea","Idea validation workflow — chain demand validation, market research, prioritization, and MVP scoping\nUse when: Validating a new product idea, testing assumptions, or exploring viability","https:\u002F\u002Fgithub.com\u002Fkonglong87\u002FsuperPM\u002Fblob\u002Fmain\u002Fskills\u002Fworkflows\u002Fvalidate-idea\u002FSKILL.md",[101],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[103,104,105,106,107,82,84,85,87,26,108,27,28,109,29,110,91,92,94],"validate","idea","validate idea","testing","research","market research","scoping","Market",{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":118,"publishedAt":31},"01M6J07HBCCG59V69N29TPAC12","plan-launch","Launch planning workflow — chain risk assessment, cross-team coordination, agile delivery, and release planning\nUse when: Preparing for a product launch, release, or go-live","https:\u002F\u002Fgithub.com\u002Fkonglong87\u002FsuperPM\u002Fblob\u002Fmain\u002Fskills\u002Fworkflows\u002Fplan-launch\u002FSKILL.md",[117],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[119,120,121,82,122,123,124,85,125,126,26,127,27,29,128,129,91,130,94,131],"launch","plan","plan launch","risk assessment","assessment","planning","risk","team","coordination","planning workflow","delivery","team coordination","for",{"skillNo":133,"name":134,"nameZh":6,"description":135,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":139,"publishedAt":31},"01M6J07DYRS1S91SY8JCZZH3CS","discover","Product discovery workflow — chain market analysis, competitor research, demand validation, and prioritization\nUse when: Exploring a new product idea, entering a new market, or validating an opportunity","https:\u002F\u002Fgithub.com\u002Fkonglong87\u002FsuperPM\u002Fblob\u002Fmain\u002Fskills\u002Fworkflows\u002Fdiscover\u002FSKILL.md",[138],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[134,107,82,84,85,140,141,87,26,27,28,142,29,110,104,143,144,91,94],"analysis","discovery","product discovery","opportunity","market analysis",{"skillNo":146,"name":147,"nameZh":6,"description":148,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":153,"publishedAt":31},"01M6J079BYTWRDH5N8WBH2NEJJ","define-strategy","Product strategy workflow — chain positioning, business model, OKRs, and roadmap\nUse when: Defining product strategy, setting OKRs, planning roadmap, or making strategic decisions","https:\u002F\u002Fgithub.com\u002Fkonglong87\u002FsuperPM\u002Fblob\u002Fmain\u002Fskills\u002Fworkflows\u002Fdefine-strategy\u002FSKILL.md",[151,152],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":74,"categoryName":75,"taxonomyType":76,"taxonomyTypeDesc":77},[154,155,156,82,124,85,26,157,158,27,28,159,29,160,161,91,162,163,164,94],"strategy","define","define strategy","model","decisions","business","roadmap","positioning","product strategy","strategic","business model",{"skillNo":166,"name":167,"nameZh":6,"description":168,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":169,"categories":170,"keywords":172,"publishedAt":31},"01M6J0752ZRR0R8FWAQHD4KTJ5","analyze-growth","Growth analysis workflow — chain AARRR analysis, data reporting, growth strategy, and iteration planning\nUse when: Analyzing growth metrics, planning growth initiatives, or optimizing product performance","https:\u002F\u002Fgithub.com\u002Fkonglong87\u002FsuperPM\u002Fblob\u002Fmain\u002Fskills\u002Fworkflows\u002Fanalyze-growth\u002FSKILL.md",[171],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[173,174,175,176,82,124,85,177,178,179,140,26,27,28,154,29,180,91,181,94],"analyze","growth","analyze growth","performance","reporting","analyzing","data","iteration","growth strategy"]