메뉴
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/ 目录⚠️ 任何一项未通过 → 补全后再标记完成。