القائمة
Use when: 有多个需求需要排定先后顺序、资源有限需决定先做什么、需求冲突需要客观评分 Do NOT use when: 只有一个需求无需排序、优先级已由上级/业务方明确指定
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Product Manager Skills Pack - Full lifecycle support from demand to delivery 让一个产品经理拥有一个产品团队的能力 Use when: Starting a new product, planning features, analyzing market, designing solutions, managing growth, strategic decision
Use when starting any product management task - automatically detects task type and invokes appropriate PM skill using intelligent routing
Use when: 需要检查super-pm skills健康状态、定期维护审计、验证元数据完整性 Do NOT use when: 正在使用某个功能skill、仅需执行产品管理任务
Use when: 有初步需求清单需要细化细节、需明确需求场景和边界条件、需求描述模糊需要结构化 Do NOT use when: 需求已足够详细可直达开发、仅需快速立项无需深入
Use when: 需要理解用户体验全链路、发现用户痛点与机会点、优化用户转化流程 Do NOT use when: 用户流程已非常清晰、仅需单一功能分析而非全局体验
Use when: 需要了解市场格局与竞争态势、收集行业数据、分析竞品优劣势、评估市场机会 Do NOT use when: 市场已有充分内部调研数据、仅需简单规模估算无需深度分析
| name | pm-priority |
| description | Use when: 有多个需求需要排定先后顺序、资源有限需决定先做什么、需求冲突需要客观评分 Do NOT use when: 只有一个需求无需排序、优先级已由上级/业务方明确指定 |
| allowed-tools | ["Read","Write","AskUserQuestion","Agent","Bash"] |
bash "$(dirname "${BASH_SOURCE[0]}")"/check-update.sh 2>/dev/null || true
# 读取技能包版本号
SKILL_ROOT="$(cd "$(dirname "${BASH_SOURCE[0]}")" 2>/dev/null && pwd)" || true
if [ -f "$SKILL_ROOT/VERSION" ]; then echo "📦 super-pm $(cat "$SKILL_ROOT/VERSION")"; fi
# 创建需求调研目录
mkdir -p docs/01-需求调研
# 检查是否有确认需求清单
if [ ! -f "docs/01-需求调研/确认需求清单.md" ]; then
echo "⚠️ 未找到确认需求清单"
echo ""
echo "建议先执行 /pm-clarify 细化需求"
echo ""
echo "您可以选择："
echo "A) 执行 /pm-clarify 先细化需求（推荐）"
echo "B) 手动输入需求列表（快速模式）"
echo "C) 从需求池导入（执行过 /pm-pool）"
fi
当流程要求与用户交互时：
如果有确认需求清单：
使用 Read 工具读取 docs/01-需求调研/确认需求清单.md
提取需求列表。
如果有需求调研报告：
使用 Read 工具读取 docs/01-需求调研/需求调研报告.md
提取初步需求列表和背景信息。
如果有市场调研报告：
使用 Read 工具读取 docs/01-需求调研/市场调研报告.md（如存在）
提取市场数据、竞品信息，为后续评分提供数据支撑。
如果没有前置文档：
进入快速模式，使用 AskUserQuestion 收集需求列表。
使用 AskUserQuestion 询问：
🎯 选择需求优先级排序模型：
A) RICE评分 - 综合Reach、Impact、Confidence、Effort（推荐） B) KANO模型 - 基于用户满意度分类需求 C) MoSCoW法则 - Must/Should/Could/Won't分类 D) 自定义权重 - 自定义评分维度
用户选择后，记录到变量 PRIORITY_MODEL
优化说明：
对每个需求，构建一个 subagent 任务：
[
{
"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) 跳过预分析，直接手动评分
同时派发所有 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 结果。
主 agent 汇总所有 subagent 的预分析结果，以表格形式展示：
## 📊 预分析评分结果（{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) 全部重新评估
优化说明：报告生成交给 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 完成报告生成。
使用 AskUserQuestion 提供下一步选项：
✅ 优先级排序完成！
📄 优先级排序报告已生成：
docs/01-需求调研/优先级排序报告.md🎯 建议下一步：
A) 执行 /pm-mvp - MVP规划，确定第一版方案（推荐） B) 执行 /pm-docs - 生成PRD文档 C) 执行 /pm-pool - 需求池管理 D) 查看优先级排序报告
主 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 分钟（串行交互）
主 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 节省
| 指标 | 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 |
提供快速模式，允许手动输入需求列表。
如果需求数量 > 15，询问用户：
⚠️ 需求数量较多（{N}个），评分可能需要较长时间
您可以选择： A) 全部评分 B) 仅对核心需求评分（前10个） C) 我来选择要评分的需求
如果某个 subagent 执行失败：
如果无前置文档可供 subagent 分析：
如果 subagent 执行失败：
v2.0.0 - Subagent 架构重构
v1.1.0 - 功能增强
v1.0.0 - 初始版本
✅ Good 示例：
- 有数据引用：「根据 Q4 数据，留存率从 35% 降至 28%」
- 有验证来源：「数据来源：Google Analytics, 2025-12-01」
- 有明确建议：「建议将新手引导步骤从 5 步减少至 3 步」
❌ Bad 示例：
- 模糊结论：「数据表明留存率有所下降」
- 无来源：「根据经验，这个功能很重要」
- 没有行动建议：「留存是个问题」
出现以下情况立即停止并回溯：
| 误区 | 正确做法 |
|---|---|
| 使用"应该"、"大概"、"看起来"做结论 | 必须基于实际数据和验证 |
| 未运行检查就声称已完成 | 先验证，再陈述 |
| 因时间紧迫跳过关键步骤 | 没有例外，时间紧更要严格 |
| "这次应该没问题"的想法 | 每次都要重新验证 |
docs/ 目录⚠️ 任何一项未通过 → 补全后再标记完成。