بنقرة واحدة
pm-roadmap
Use when: 需要规划产品中长期发展、设定里程碑、对齐团队方向、制定季度/年度计划 Do NOT use when: 短期执行无需长期规划、方向已锁定无需路线图
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
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-roadmap |
| description | Use when: 需要规划产品中长期发展、设定里程碑、对齐团队方向、制定季度/年度计划 Do NOT use when: 短期执行无需长期规划、方向已锁定无需路线图 |
| allowed-tools | ["Agent","Read","Write","AskUserQuestion","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/03-增长迭代
echo "🗺️ 产品路线图工具已启动"
# 检查前置文档
echo "📊 正在检查前置数据..."
if [ -f "docs/02-方案设计/PRD产品需求文档.md" ]; then
echo "✅ PRD文档 - 已找到"
else
echo "⏳ PRD文档 - 未找到"
fi
当流程要求与用户交互时:
使用 AskUserQuestion 询问:
🎯 产品愿景与战略目标
产品愿景:产品最终要成为什么? 示例:成为XX领域最受信赖的平台
时间范围:您想规划多长时间的路线图?
A) 3个月(近期规划) B) 6个月(中期规划) C) 12个月(年度规划) D) 2-3年(长期规划) E) 其他(请手动输入)
💡 提示:首次规划建议从6个月开始
记录到变量 VISION 和 TIMEFRAME
🎯 各阶段核心目标:
将{TIMEFRAME}划分为2-4个阶段,每个阶段设定一个核心目标。
示例(电商产品6个月路线图):
阶段 时间 核心目标 关键指标 阶段1 第1-2月 MVP上线验证 DAU达到1万 阶段2 第3-4月 用户增长 MAU达到10万 阶段3 第5-6月 商业变现 GMV达到100万 您希望如何划分阶段?
A) 根据功能主题划分(基础设施→核心功能→增长→变现) B) 根据用户规模划分(冷启动→增长→规模化) C) 根据商业目标划分(验证→获客→变现) D) 自定义划分(请手动输入)
对每个阶段,详细规划里程碑:
📅 阶段1详细规划
阶段名称:{阶段名称} 时间范围:{起止时间} 核心目标:{目标描述}
关键里程碑:
里程碑 时间 交付物 验收标准 M1 第X周 核心功能A上线 完成XX功能,达标XX指标 M2 第X周 核心功能B上线 完成XX功能,达标XX指标 M3 第X周 公测版本发布 完成全流程验证 关键指标目标:
- DAU目标:[X]万
- 转化率目标:[X]%
- NPS目标:[X]分
资源需求:
- 前端:[X]人
- 后端:[X]人
- 设计:[X]人
是否调整阶段1的规划?
A) 阶段1规划合理,继续阶段2 B) 需要调整里程碑 C) 需要调整资源分配
逐个阶段确认。
⚠️ 关键依赖与风险分析:
外部依赖:
- 第三方服务(支付、短信、地图等)
- 资质合规(牌照、备案等)
- 合作伙伴对接
内部依赖:
- 关键人员(核心开发、设计师)
- 技术基建(数据库、服务器)
- 数据基础设施
主要风险:
风险 概率 影响 应对措施 开发延期 高 里程碑延迟 预留20%缓冲时间 政策变化 中 产品方向调整 关注政策动态 竞品先发 中 市场空间压缩 快速验证,快速迭代 是否还有其他风险需要补充?
使用 Write 工具创建 docs/03-增长迭代/产品路线图.md:
# {产品名称} 产品路线图
## 一、产品愿景
**愿景**:{VISION}
**规划周期**:{TIMEFRAME}
**战略目标**:
1. {目标1}
2. {目标2}
3. {目标3}
---
## 二、阶段规划总览
| 阶段 | 时间 | 核心目标 | 关键指标 | 里程碑数 |
|------|------|---------|---------|---------|
| 阶段1 | M1-M2 | {目标} | {指标} | 3 |
| 阶段2 | M3-M4 | {目标} | {指标} | 3 |
| 阶段3 | M5-M6 | {目标} | {指标} | 2 |
---
## 三、详细里程碑
### 阶段1: {名称}(M1-M2)
**核心目标**:{描述}
**里程碑**:
1. **M1**(第X周):{交付物}
- 验收标准:{标准}
2. **M2**(第X周):{交付物}
- 验收标准:{标准}
3. **M3**(第X周):{交付物}
- 验收标准:{标准}
**所需资源**:前端X人,后端X人,设计X人
---
## 四、关键依赖
| 依赖项 | 类型 | 状态 | 负责人 |
|--------|------|------|--------|
| {依赖项} | 外部/内部 | 已确认/待确认 | {负责人} |
## 五、风险与应对
| 风险 | 概率 | 影响 | 应对措施 |
|------|------|------|---------|
| {风险} | 高/中/低 | 高/中/低 | {措施} |
## 六、路线图变更记录
| 版本 | 日期 | 变更内容 | 原因 |
|------|------|---------|------|
| v1.0 | {日期} | 初始版本 | - |
---
**文档状态**: 产品路线图规划完成
**生成时间**: {时间戳}
**生成工具**: super-pm
✅ 产品路线图完成!
📄 已生成:
docs/03-增长迭代/产品路线图.md🎯 建议下一步:
A) 执行 /pm-iteration - 制定近期迭代计划 B) 执行 /pm-risk - 风险管控方案 C) 执行 /pm-roadmap - 查看/更新路线图
if [ -f "docs/03-增长迭代/产品路线图.md" ]; then
echo "⚠️ 检测到已有产品路线图"
fi
提供选项:查看/更新/重新规划。
✅ Good 示例:
- 有数据引用:「根据 Q4 数据,留存率从 35% 降至 28%」
- 有验证来源:「数据来源:Google Analytics, 2025-12-01」
- 有明确建议:「建议将新手引导步骤从 5 步减少至 3 步」
❌ Bad 示例:
- 模糊结论:「数据表明留存率有所下降」
- 无来源:「根据经验,这个功能很重要」
- 没有行动建议:「留存是个问题」
出现以下情况立即停止并回溯:
| 误区 | 正确做法 |
|---|---|
| 使用"应该"、"大概"、"看起来"做结论 | 必须基于实际数据和验证 |
| 未运行检查就声称已完成 | 先验证,再陈述 |
| 因时间紧迫跳过关键步骤 | 没有例外,时间紧更要严格 |
| "这次应该没问题"的想法 | 每次都要重新验证 |
docs/ 目录⚠️ 任何一项未通过 → 补全后再标记完成。