pm-priority

Preamble (run first)

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

Boundaries when writing

When only discussing, do not write files; the startup check does not create directories. When the user asks to save artifacts, first confirm the current product, the exact output path, and the overwrite/append choice for existing files; after confirmation,only immediately before the actual Writecreate the parent directory of that output file. For complete installation, see skills/_shared/artifact-policy.md, and installing this skill alone also follows this paragraph.

Cross-Agent interaction rules

When the process requires interaction with the user:

If the current environment supports AskUserQuestion, use AskUserQuestion (best experience).
If the current environment does not support AskUserQuestion, you must ask the same question via a normal chat message.
Ask only one question at a time.
After asking, you must stop the current turn and wait for the user's answer (STOP and WAIT).
Do not generate documents or write to docs before the user answers.
Existing docs files cannot substitute for the user's answer in this round.

Output requirements: for each ranked item, retain the requirement identifier, evidence source and date, scoring basis, and confidence level; mark missing data as assumptions, and do not pass off estimates as facts. Pass the final trade-offs and responsible persons to the MVP plan.

RICE gate for missing data: If a requirement only has placeholder codes such as A/B/C and lacks Reach or Effort estimates, you must not fill in any precise values or calculate example scores for A/B/C; even writing "assumption" or "example only" will make the placeholders appear to have already been ranked. Provide only a blank input table, the formula, the data to be filled in, and one key clarifying question, then STOP and WAIT. Only after obtaining the meaning of each requirement and estimates on the same basis may you calculate or display ranges marked with assumptions.

Execution flow

Step 1: Read prerequisite data (main agent)

If there is a confirmed requirements list：

Use the Read tool to read docs/01-需求调研/确认需求清单.md

Extract the requirements list.

If there is a requirements research report：

Use the Read tool to read docs/01-需求调研/需求调研报告.md

Extract the preliminary requirements list and background information.

If there is a market research report：

Use the Read tool to read docs/01-需求调研/市场调研报告.md(if it exists)

Extract market data and competitor information to provide data support for subsequent scoring.

If there are no prerequisite documents：

Enter quick mode and use AskUserQuestion to collect the requirements list.

Step 2: Choose a prioritization model (main agent - user interaction)

Use AskUserQuestion to ask:

🎯 Choose a requirements prioritization model:

A) RICE scoring - combines Reach, Impact, Confidence, Effort (recommended) B) KANO model - classifies requirements based on user satisfaction C) MoSCoW method - Must/Should/Could/Won't classification D) Custom weights - custom scoring dimensions

After the user chooses, record it in the variable PRIORITY_MODEL

Step 3: Subagent parallel pre-analysis (v2.0 core optimization)

Optimization note：

Dispatch one subagent per requirement, read all prerequisite documents, and generate initial scoring suggestions based on the data and the chosen model
Analyze multiple requirements in parallel, so the total time equals the analysis time of a single requirement
The pre-analysis result includes a score + data evidence, and the user only needs to confirm or fine-tune
Greatly reduces the number of interaction rounds of asking dimension by dimension

3.1 Build pre-analysis tasks

For each requirement, build a subagent task:

[
  {
    "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"]
  }
]

If the number of requirements > 10, prompt the user:

⚠️ There are many requirements ({N}), and pre-analysis may take a long time

You can choose: A) Pre-analyze all B) Pre-analyze only the core requirements (the first 10) C) Skip pre-analysis and score manually

3.2 Dispatch subagents in parallel

Dispatch all subagents at the same time:

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

Prompt template for each subagent:

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

The main agent waits for all subagents to complete, and collects the JSON results.

Step 4: User confirms/adjusts scores (main agent)

The main agent aggregates the pre-analysis results of all subagents and displays them in table form:

## 📊 预分析评分结果（{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，在此展示}

Use AskUserQuestion to confirm requirement by requirement:

📝 Confirm the score for "{requirement name}":

Current pre-score: Reach={R} Impact={I} Confidence={C} Effort={E} → RICE={score}

A) Confirm, no adjustment needed B) Adjust Reach C) Adjust Impact D) Adjust Confidence E) Adjust Effort F) Re-evaluate this requirement

💡 Evidence: {subagent key_evidence}

Quick confirmation mode(number of requirements ≤ 5):

✅ Do you approve the above pre-score results?

A) Confirm all and generate the report directly (recommended) B) Adjust one by one C) Re-evaluate all

Step 5: Subagent generates the prioritization report (v2.0 optimization)

Optimization note: report generation is handed off to a subagent, keeping the main agent's context clean

Use the Agent tool to dispatch a subagent to generate the report:

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 格式正确、表格对齐

The main agent waits for the subagent to complete report generation。

Step 6: Output completion prompt (main agent)

Use AskUserQuestion to provide next-step options:

✅ Prioritization complete!

📄 The prioritization report has been generated:docs/01-需求调研/优先级排序报告.md

🎯 Suggested next steps:

A) Run /pm-mvp - MVP planning to determine the first version plan (recommended) B) Run /pm-docs - Generate the PRD document C) Run /pm-pool - Requirement pool management D) View the prioritization report

Comparison: before vs after optimization

Before optimization (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 分钟（串行交互）

After optimization (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 usage comparison

Metric	v1.1.0	v2.0.0	Improvement
Main agent tokens	~5,000	~400	-92%
Subagent token	0	~2,500	N/A
Interaction rounds	22	4-5	-80%
Total time	5-8 min	1.5-3 min	2.5-3x

Key optimization points

1. Context savings

✅ The dimension-by-dimension scoring dialogue does not occupy the main agent's context
✅ The report generation template does not occupy the main agent's context
✅ The main agent only processes structured scoring data
✅ Token usage reduced by 90%+

2. Execution efficiency

✅ Multiple requirements are pre-analyzed in parallel
✅ Users only need to confirm rather than answer dimension by dimension
✅ Interaction rounds reduced from 22 to 4-5
✅ Total time reduced by 60-70%

3. Scoring quality

✅ Pre-analysis is based on upstream document data, reducing subjective guessing
✅ Every score has a clear basis (key_evidence)
✅ Data uncertainty is flagged in risk_flag
✅ The user retains final decision-making authority

Fallback Mechanism

Scenario 1: No Requirements List

Provide a quick mode, allowing manual entry of the requirements list.

Scenario 2: Too Many Requirements

If the number of requirements > 15, ask the user:

⚠️ There are many requirements ({N}), and scoring may take a long time

You can choose: A) Score all B) Score only the core requirements (top 10) C) I will select the requirements to score

Scenario 3: Subagent Pre-analysis Failure

If a subagent fails to execute:

The main agent detects the error
Mark the requirement as "needs manual scoring"
Continue the confirmation process for the remaining requirements
For the failed requirement, downgrade to manually asking about each dimension

Scenario 4: No Pre-existing Documents (Quick Mode)

If there are no pre-existing documents available for subagent analysis:

Skip Step 3 (pre-analysis)
Enter manual scoring mode directly (original v1.1.0 process)
Still use subagents to generate the report (Step 5)

Exception Handling