Pm Priority

---
name: pm-priority
description: |
  Use when: 有多个需求需要排定先后顺序、资源有限需决定先做什么、需求冲突需要客观评分
  Do NOT use when: 只有一个需求无需排序、优先级已由上级/业务方明确指定
allowed-tools:
  - Read
  - Write
  - AskUserQuestion
  - Agent
  - Bash
---

## Preamble (run first)

```bash
# 检查是否有确认需求清单
if [ ! -f "docs/01-需求调研/确认需求清单.md" ]; then
  echo "⚠️  未找到确认需求清单"
  echo ""
  echo "建议先执行 /pm-clarify 细化需求"
  echo ""
  echo "您可以选择："
  echo "A) 执行 /pm-clarify 先细化需求（推荐）"
  echo "B) 手动输入需求列表（快速模式）"
  echo "C) 从需求池导入（执行过 /pm-pool）"
fi
```

---

## 写入时边界

只讨论时不写文件，启动检查不创建目录。用户要求保存产物时，先确认当前产品、精确输出路径及已有文件的覆盖/追加选择；确认后**仅在实际 Write 前**创建该输出文件的父目录。完整安装可参见 `skills/_shared/artifact-policy.md`，单独安装本 skill 也按本段执行。

---

## 跨 Agent 交互规则

当流程要求与用户交互时：

1. 如果当前环境支持 AskUserQuestion，使用 AskUserQuestion（最佳体验）。
2. 如果当前环境不支持 AskUserQuestion，必须用普通聊天消息提出同样问题。
3. 一次只问一个问题。
4. 提问后必须停止当前回合，等待用户回答（STOP and WAIT）。
5. 不得在用户回答前生成文档、写入 docs。
6. 已有 docs 文件不能替代本轮用户回答。

---

产出要求：每项排序保留需求标识、证据来源及日期、评分依据和置信度；缺失数据标为假设，不以估算冒充事实。将最终取舍及责任人传递给 MVP 方案。

**缺数据的 RICE 门禁**：如果需求只有 A/B/C 之类占位代号，且缺少 Reach（覆盖人数）或 Effort（工作量）估计，不得替 A/B/C 填任何精确数值或计算示例分数；即使写“假设”“仅示例”也会让占位符看起来已有排序。只给空白输入表、公式、待补的数据和一个关键澄清问题，STOP and WAIT。获得各需求含义和同口径的估计后，才可计算或展示标注假设的区间。

## 执行流程


### 步骤 1: 读取前置数据（主 agent）

**如果有确认需求清单**：

使用 Read 工具读取 `docs/01-需求调研/确认需求清单.md`

提取需求列表。

**如果有需求调研报告**：

使用 Read 工具读取 `docs/01-需求调研/需求调研报告.md`

提取初步需求列表和背景信息。

**如果有市场调研报告**：

使用 Read 工具读取 `docs/01-需求调研/市场调研报告.md`（如存在）

提取市场数据、竞品信息，为后续评分提供数据支撑。

**如果没有前置文档**：

进入快速模式，使用 AskUserQuestion 收集需求列表。

---

### 步骤 2: 选择排序模型（主 agent - 用户交互）

使用 AskUserQuestion 询问：

> 🎯 选择需求优先级排序模型：
>
> A) RICE评分 - 综合Reach、Impact、Confidence、Effort（推荐）
> B) KANO模型 - 基于用户满意度分类需求
> C)  MoSCoW法则 - Must/Should/Could/Won't分类
> D) 自定义权重 - 自定义评分维度

用户选择后，记录到变量 `PRIORITY_MODEL`

---

### 步骤 3: Subagent 并行预分析（v2.0 核心优化）

**优化说明**：
- 每个需求派发一个 subagent，读取所有前置文档，基于数据和所选模型生成初始评分建议
- 多个需求并行分析，总耗时等于单个需求分析时间
- 预分析结果包含评分 + 数据依据，用户只需确认或微调
- 大幅减少逐维度询问的交互轮次

---

#### 3.1 构建预分析任务

对每个需求，构建一个 subagent 任务：

```json
[
  {
    "task_id": "prescore_req_1",
    "requirement": "{需求1名称}",
    "model": "{PRIORITY_MODEL}",
    "docs": ["docs/01-需求调研/确认需求清单.md", "docs/01-需求调研/需求调研报告.md"]
  },
  {
    "task_id": "prescore_req_2",
    "requirement": "{需求2名称}",
    "model": "{PRIORITY_MODEL}",
    "docs": ["docs/01-需求调研/确认需求清单.md", "docs/01-需求调研/需求调研报告.md"]
  }
]
```

**如果需求数量 > 10**，提示用户：

> ⚠️ 需求数量较多（{N}个），预分析可能需要较长时间
>
> 您可以选择：
> A) 全部预分析
> B) 仅对核心需求预分析（前10个）
> C) 跳过预分析，直接手动评分

---

#### 3.2 并行派发 subagent

同时派发所有 subagent：

```
# 并行派发 N 个 subagent
Agent 1: 预分析-{需求1}
Agent 2: 预分析-{需求2}
...
Agent N: 预分析-{需求N}
```

每个 subagent 的 prompt 模板：

```
Tool: Agent
Parameters:
  subagent_type: "general-purpose"
  description: "预分析-{需求名称}"
  prompt: |
    你是一个产品优先级分析专家。请基于前置文档，为指定需求生成评分建议。

    **需求名称**: {需求名称}
    **排序模型**: {PRIORITY_MODEL}
    **前置文档路径**:
    - docs/01-需求调研/确认需求清单.md
    - docs/01-需求调研/需求调研报告.md
    - docs/01-需求调研/市场调研报告.md（如存在）

    **任务**：
    1. 使用 Read 工具读取上述前置文档
    2. 根据排序模型，分析该需求的评分维度
    3. 给出每个维度的建议评分和依据

    ---

    #### 如果选择 RICE 评分：

    对指定需求，分析以下 4 个维度：

    **Reach（覆盖人数）**:
    - 10分: 全部用户
    - 7分: 大部分用户（50-80%）
    - 5分: 部分用户（20-50%）
    - 3分: 少量用户（<20%）

    **Impact（影响程度）**:
    - 10分: 极大影响 - 直接影响核心指标
    - 7分: 较大影响 - 显著提升指标
    - 5分: 中等影响 - 有一定提升
    - 3分: 较小影响 - 影响有限

    **Confidence（信心度）**:
    - 10分: 非常有信心 - 有数据或调研支持
    - 7分: 较有信心 - 有一定依据
    - 5分: 中等信心 - 基于假设
    - 3分: 信心不足 - 猜测或不确定

    **Effort（投入成本）**:
    - 10分: 很小 - 1-2人天
    - 8分: 较小 - 3-5人天
    - 5分: 中等 - 1-2人周
    - 3分: 较大 - 2-4人周
    - 1分: 很大 - >1人月

    ---

    #### 如果选择 KANO 模型：

    分析该需求属于哪类：
    - 基本型需求 - 必须有，没有用户会很不满意
    - 期望型需求 - 越完善用户越满意
    - 魅力型需求 - 没有没关系，有了会惊喜
    - 无差异需求 - 有没有都无所谓
    - 反向型需求 - 有了反而用户不满

    ---

    #### 如果选择 MoSCoW 法则：

    分析该需求的优先级：
    - Must have - 必须有，否则产品无法使用
    - Should have - 应该有，重要但非紧急
    - Could have - 可以有，锦上添花
    - Won't have - 本期不做，后续考虑

    ---

    #### 如果选择自定义权重：

    分析该需求在以下维度的表现（1-10分）：
    - 用户价值
    - 商业价值
    - 技术可行性
    - 战略契合度

    ---

    **输出格式**（JSON）：
    ```json
    {
      "requirement": "{需求名称}",
      "model": "{PRIORITY_MODEL}",
      "scores": {
        "reach": {"score": 7, "reasoning": "依据文档中的用户规模数据..."},
        "impact": {"score": 8, "reasoning": "该需求直接解决文档中提到的核心痛点..."},
        "confidence": {"score": 7, "reasoning": "市场调研报告中有相关数据支撑..."},
        "effort": {"score": 5, "reasoning": "基于需求复杂度评估..."}
      },
      "rice_score": "（自动计算: Reach × Impact × Confidence / Effort）",
      "key_evidence": ["支撑依据1", "支撑依据2"],
      "risk_flag": "如有数据矛盾或不确定性，在此标注"
    }
    ```

    **重要**：
    - 评分必须有前置文档中的数据支撑，不能凭空猜测
    - 如果文档中没有足够信息，在 risk_flag 中标明不确定性
    - 用中文返回 reasoning 和 key_evidence
```

**主 agent 等待所有 subagent 完成**，收集 JSON 结果。

---

### 步骤 4: 用户确认/调整评分（主 agent）

主 agent 汇总所有 subagent 的预分析结果，以表格形式展示：

```markdown
## 📊 预分析评分结果（{PRIORITY_MODEL}）

| 需求 | Reach | Impact | Confidence | Effort | RICE得分 | 预分级 |
|------|-------|--------|------------|--------|----------|--------|
| {需求1} | 7 | 8 | 7 | 5 | 78.4 | P0 |
| {需求2} | 5 | 7 | 6 | 8 | 26.3 | P1 |
| {需求3} | 3 | 5 | 5 | 3 | 25.0 | P2 |

**关键依据**：
- {需求1}：{subagent 返回的 key_evidence}
- {需求2}：{subagent 返回的 key_evidence}

**风险提示**：
- {如有 risk_flag，在此展示}
```

使用 AskUserQuestion 逐需求确认：

> 📝 确认"{需求名称}"的评分：
>
> 当前预评分：Reach={R} Impact={I} Confidence={C} Effort={E} → RICE={得分}
>
> A) 确认，无需调整
> B) 调整 Reach
> C) 调整 Impact
> D) 调整 Confidence
> E) 调整 Effort
> F) 重新评估此需求
>
> 💡 依据：{subagent key_evidence}

**快速确认模式**（需求数量 ≤ 5）：

> ✅ 以上预评分结果是否认可？
>
> A) 全部确认，直接生成报告（推荐）
> B) 逐个调整
> C) 全部重新评估

---

### 步骤 5: Subagent 生成优先级排序报告（v2.0 优化）

**优化说明**：报告生成交给 subagent，主 agent 上下文保持清爽

使用 Agent 工具派发 subagent 生成报告：

```
Tool: Agent
Parameters:
  subagent_type: "general-purpose"
  description: "生成优先级排序报告"
  prompt: |
    你是一个产品文档专家。请根据以下数据生成优先级排序报告。

    **排序模型**: {PRIORITY_MODEL}
    **需求评分数据**:
    ```json
    {所有需求的最终评分 JSON}
    ```

    **报告要求**：
    1. 使用 Write 工具保存到 `docs/01-需求调研/优先级排序报告.md`
    2. 严格按照以下模板格式
    3. P0/P1/P2/P3 分级规则：
       - P0: RICE ≥ 50 或 Must have / 基本型
       - P1: RICE 20-49 或 Should have / 期望型
       - P2: RICE 5-19 或 Could have / 魅力型
       - P3: RICE < 5 或 Won't have / 无差异/反向型

    **报告模板**：

    ```markdown
    # 优先级排序报告

    ## 一、基础信息

    - **排序模型**: {PRIORITY_MODEL}
    - **需求数量**: {N}个
    - **生成时间**: {当前时间}

    ---

    ## 二、排序结果

    ### 2.1 需求优先级列表

    | 排名 | 需求名称 | {模型对应列头} | 优先级 |
    |------|----------|{列头}|--------|
    | 1 | {需求1} | {得分} | P0 |
    | 2 | {需求2} | {得分} | P0 |
    | 3 | {需求3} | {得分} | P1 |
    | ... | ... | ... | ... |

    ### 2.2 优先级分组

    **P0 - 核心需求（必须做）**:
    1. {需求1} - {得分详情}
    2. {需求2} - {得分详情}

    **P1 - 重要需求（应该做）**:
    1. {需求3} - {得分详情}

    **P2 - 次要需求（可以做）**:
    1. {需求4} - {得分详情}

    **P3 - 待定需求（暂缓）**:
    1. {需求5} - {得分详情}

    ---

    ## 三、评分详情

    逐需求展开评分依据：

    ### {需求1}

    | 维度 | 评分 | 依据 |
    |------|------|------|
    | Reach | {R} | {reasoning} |
    | Impact | {I} | {reasoning} |
    | Confidence | {C} | {reasoning} |
    | Effort | {E} | {reasoning} |
    | **RICE** | **{得分}** | = {R}×{I}×{C}/{E} |

    ...

    ---

    ## 四、排序依据

    ### {模型评分说明}

    （根据实际使用的模型展开评分规则说明）

    ---

    ## 五、实施建议

    ### 5.1 MVP范围建议

    建议第一版（MVP）包含 P0 级需求，共 {N} 个需求：

    1. {需求1}
    2. {需求2}
    ...

    预计工作量: {估算}

    ### 5.2 后续迭代

    **第二版（V1.1）**: P1级需求
    **第三版（V1.2）**: P2级需求

    ---

    ## 六、下一步建议

    建议执行：

    1. **/pm-mvp** - MVP规划，确定第一版具体方案（推荐）
    2. **/pm-docs** - 生成PRD文档
    3. **/pm-pool** - 需求池管理，长期跟踪需求

    ---

    **项目状态**: 优先级排序完成
    **生成时间**: {时间戳}
    **生成工具**: super-pm
    ```

    **注意**：
    - 如果模型是 KANO 或 MoSCoW，调整列头和评分显示格式
    - 评分依据来自步骤3 subagent 返回的 reasoning
    - 确保 Markdown 格式正确、表格对齐
```

**主 agent 等待 subagent 完成报告生成**。

---

### 步骤 6: 输出完成提示（主 agent）

使用 AskUserQuestion 提供下一步选项：

> ✅ 优先级排序完成！
>
> 📄 优先级排序报告已生成：`docs/01-需求调研/优先级排序报告.md`
>
> 🎯 建议下一步：
>
> A) 执行 /pm-mvp - MVP规划，确定第一版方案（推荐）
> B) 执行 /pm-docs - 生成PRD文档
> C) 执行 /pm-pool - 需求池管理
> D) 查看优先级排序报告

---

## 对比：优化前 vs 优化后

### 优化前（pm-priority v1.1.0）

```
主 agent 执行流程：
1. 读取前置数据（50 tokens）
2. 询问排序模型（10 tokens）
3. 对需求1逐维度询问（4轮交互，每轮 ~200 tokens）
4. 对需求2逐维度询问（4轮交互，每轮 ~200 tokens）
5. 对需求N逐维度询问...
6. 汇总计算（50 tokens）
7. 生成报告（~800 tokens 写入）

总计（以5个需求为例）：
- 交互轮次：1 + 1 + 5×4 = 22 轮
- 上下文消耗：~5,000 tokens（报告模板占用大头）
- 耗时：约 5-8 分钟（串行交互）
```

### 优化后（pm-priority v2.0.0）

```
主 agent 执行流程：
1. 读取前置数据（50 tokens）
2. 询问排序模型（10 tokens）
3. 并行派发 subagent 预分析（20 tokens × N个任务）
   └─ 每个 Subagent 读取文档 + 分析（不占用主 agent 上下文）
4. 展示预评分 + 确认（200 tokens，1-2轮交互）
5. 派发 subagent 生成报告（20 tokens）
   └─ Subagent 生成报告（不占用主 agent 上下文）
6. 输出完成提示（10 tokens）

总计（以5个需求为例）：
- 交互轮次：1 + 1 + 1-2 + 1 = 4-5 轮
- 主 agent 上下文消耗：~400 tokens（减少 90%+）
- 耗时：约 1.5-3 分钟（并行分析 + 快速确认）
- 效率提升：4x 交互减少，5x+ token 节省
```

### Token 使用对比

| 指标 | v1.1.0 | v2.0.0 | 改善 |
|------|--------|--------|------|
| 主 agent token | ~5,000 | ~400 | -92% |
| Subagent token | 0 | ~2,500 | N/A |
| 交互轮次 | 22 | 4-5 | -80% |
| 总耗时 | 5-8 min | 1.5-3 min | 2.5-3x |

---

## 关键优化点

### 1. 上下文节省
- ✅ 逐维度评分对话不占用主 agent 上下文
- ✅ 报告生成模板不占用主 agent 上下文
- ✅ 主 agent 只处理结构化评分数据
- ✅ Token 使用减少 90%+

### 2. 执行效率
- ✅ 多个需求并行预分析
- ✅ 用户只需确认而非逐维度回答
- ✅ 交互轮次从 22 轮降至 4-5 轮
- ✅ 总耗时减少 60-70%

### 3. 评分质量
- ✅ 预分析基于前置文档数据，减少主观猜测
- ✅ 每个评分都有明确依据（key_evidence）
- ✅ 数据不确定性在 risk_flag 中标注
- ✅ 用户保留最终决策权

---

## 兜底机制

### 场景 1: 无需求清单

提供快速模式，允许手动输入需求列表。

### 场景 2: 需求数量过多

如果需求数量 > 15，询问用户：

> ⚠️ 需求数量较多（{N}个），评分可能需要较长时间
>
> 您可以选择：
> A) 全部评分
> B) 仅对核心需求评分（前10个）
> C) 我来选择要评分的需求

### 场景 3: Subagent 预分析失败

如果某个 subagent 执行失败：

1. 主 agent 检测到错误
2. 标记该需求为"需手动评分"
3. 对其余需求继续确认流程
4. 对失败的需求，降级为手动逐维度询问

### 场景 4: 无前置文档（快速模式）

如果无前置文档可供 subagent 分析：

1. 跳过步骤 3（预分析）
2. 直接进入手动评分模式（原 v1.1.0 流程）
3. 仍然使用 subagent 生成报告（步骤 5）

---

## 异常处理

如果 subagent 执行失败：
1. 主 agent 检测到错误
2. 提供降级方案：手动逐需求评分（原 v1.1.0 模式）
3. 记录错误信息供用户排查

---

## 版本说明

**v2.0.0** - Subagent 架构重构
- 新增 Agent 工具支持
- 需求预分析并行化（Subagent 读取文档 + 评分建议）
- 报告生成 Subagent 化
- 交互轮次减少 80%
- Token 节省 90%+
- 评分增加数据依据追溯

**v1.1.0** - 功能增强
- 新增自定义权重评分模型
- 需求数量 > 15 的分批处理

**v1.0.0** - 初始版本
- RICE/KANO/MoSCoW 三种排序模型
- 逐需求交互评分
- 优先级排序报告生成

---

## 注意事项

1. **一次一个需求确认**：避免用户负担过重
2. **评分标准明确**：每个选项对应明确分数
3. **RICE计算自动**：AI自动计算得分
4. **优先级分组**：P0/P1/P2/P3便于后续决策
5. **Markdown存储**：排序报告人类可读可编辑
6. **Subagent 预分析**：基于文档数据的评分建议，用户拥有最终决定权

---

## 输出质量对比

**✅ Good 示例**：
```
- 有数据引用：「根据 Q4 数据，留存率从 35% 降至 28%」
- 有验证来源：「数据来源：Google Analytics, 2025-12-01」
- 有明确建议：「建议将新手引导步骤从 5 步减少至 3 步」
```

**❌ Bad 示例**：
```
- 模糊结论：「数据表明留存率有所下降」
- 无来源：「根据经验，这个功能很重要」
- 没有行动建议：「留存是个问题」
```

---

## 常见误区 / Red Flags — STOP

出现以下情况立即停止并回溯：

| 误区 | 正确做法 |
|------|---------|
| 使用"应该"、"大概"、"看起来"做结论 | 必须基于实际数据和验证 |
| 未运行检查就声称已完成 | 先验证，再陈述 |
| 因时间紧迫跳过关键步骤 | 没有例外，时间紧更要严格 |
| "这次应该没问题"的想法 | 每次都要重新验证 |

---

## 产出质量检查 / Verification Checklist

- [ ] 前置依赖已满足（输入文档/数据已收集）
- [ ] 核心步骤已全部执行
- [ ] 输出文档已生成到 `docs/` 目录
- [ ] 每个评分都有数据/证据支撑
- [ ] 已推荐 2-3 个后续 skill

> ⚠️ 任何一项未通过 → 补全后再标记完成。

---