pm-evidence-audit
Use when: 审核产品调研、市场分析、增长报告或 PRD 中的关键结论是否有可追溯证据,核对来源、日期、推断与冲突 Do NOT use when: 只需评审 PRD 的完整性和表达(用 pm-prd-review)、仅需撰写新报告而非审查现有主张
Use when: 有多个需求需要排定先后顺序、资源有限需决定先做什么、需求冲突需要客观评分 Do NOT use when: 只有一个需求无需排序、优先级已由上级/业务方明确指定
Claude Code
$ npx -y skills add konglong87/superPM --skill pm-priority --agent claude-code
Codex
$ npx skills add konglong87/superPM --skill pm-priority -a codex -y
Cursor
$ npx skills add konglong87/superPM --skill pm-priority -a cursor -y
Gemini CLI
$ npx skills add konglong87/superPM --skill pm-priority -a gemini-cli -y
GitHub Copilot
$ npx skills add konglong87/superPM --skill pm-priority -a github-copilot -y
OpenCode
$ npx skills add konglong87/superPM --skill pm-priority -a opencode -y
Windsurf
$ npx skills add konglong87/superPM --skill pm-priority -a windsurf -y
name: pm-priority description: | Use when: 有多个需求需要排定先后顺序、资源有限需决定先做什么、需求冲突需要客观评分 Do NOT use when: 只有一个需求无需排序、优先级已由上级/业务方明确指定 allowed-tools: - Read - Write - AskUserQuestion - Agent - 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 也按本段执行。
---
当流程要求与用户交互时:
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。获得各需求含义和同口径的估计后,才可计算或展示标注假设的区间。
**如果有确认需求清单**:
使用 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": "如有数据矛盾或不确定性,在此标注"
}**重要**:
**主 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) 全部重新评估
---
**优化说明**:报告生成交给 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 分级规则:
Use when: 审核产品调研、市场分析、增长报告或 PRD 中的关键结论是否有可追溯证据,核对来源、日期、推断与冲突 Do NOT use when: 只需评审 PRD 的完整性和表达(用 pm-prd-review)、仅需撰写新报告而非审查现有主张
Use when: 需要检查 super-pm 技能包安装完整性、元数据和体积 Do NOT use when: 正在执行具体 PM 任务且不需要安装诊断
Use when the user explicitly invokes /prompt-pe or explicitly asks to clarify, enhance, or rewrite a vague prompt Do NOT use for…
Use when: 需要创意方案、探索产品方向、发散思维、本质问题分析 用户说"我想做一个XX""帮我规划XX产品""帮我设计一下需求" 用户给出新产品方向,但尚未完成本轮 brainstorm 交互确认 新产品从0到1的第一步 Do NOT use…
Use when: 有初步需求清单需要细化细节、需明确需求场景和边界条件、需求描述模糊需要结构化 Do NOT use when: 需求已足够详细可直达开发、仅需快速立项无需深入
Use when: 需要持续监控竞品动态、建立竞品情报预警、定期输出竞品监控月报、追踪竞品版本/定价/功能/舆情/融资异动 Do NOT use when: 仅需一次性竞品调研(用 pm-market / pm-search…
Shape output for a reader with ADHD: lead with the next action, number multi-step work, restate state across turns, suppress…
Set up the owner profile so a personal agent knows who it works for (first-run setup, \"get to know me\"), or distill colleague,…