pm-roadmap

Preamble

echo "🗺️  产品路线图工具已启动"

# 检查前置文档
echo "📊 正在检查前置数据..."
if [ -f "docs/02-方案设计/PRD产品需求文档.md" ]; then
  echo "✅ PRD文档 - 已找到"
else
  echo "⏳ PRD文档 - 未找到"
fi

---

Write boundaries

When only discussing, do not write files; during startup checks, do not create directories. When the user requests saving 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; installing this skill alone also follows this paragraph.

---

Cross-Agent interaction rules

When the process requires interaction with the user:

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

---

Execution process

Step 1: Clarify the product vision and strategic goals

Use AskUserQuestion to ask:

🎯 Product vision and strategic goals

Product vision: What should the product ultimately become? Example: Become the most trusted platform in the XX field

Time range: How long a roadmap do you want to plan?

A) 3 months (near-term planning) B) 6 months (mid-term planning) C) 12 months (annual planning) D) 2-3 years (long-term planning) E) Other (please enter manually)

💡 Tip: For first-time planning, it is recommended to start with 6 months

Record to variables VISION and TIMEFRAME

---

Step 2: Set core goals

🎯 Core goals for each phase:

Divide {TIMEFRAME} into 2-4 phases, and set one core goal for each phase.

Example (6-month roadmap for an e-commerce product)：

Phase	Time	Core goal	Key metric
Phase 1	Months 1-2	MVP launch validation	DAU reaches 10,000
Phase 2	Months 3-4	User growth	MAU reaches 100,000
Phase 3	Months 5-6	Monetization	GMV reaches 1 million

How would you like to divide the phases?

A) Divide by functional themes (infrastructure → core features → growth → monetization) B) Divide by user scale (cold start → growth → scaling) C) Divide by business goals (validation → customer acquisition → monetization) D) Custom division (please enter manually)

---

Step 3: Plan milestones for each phase

For each phase, plan milestones in detail:

📅 Detailed planning for Phase 1

Phase name: {phase name} Time range: {start and end time} Core goal: {goal description}

Key milestones：

Milestone	Time	Deliverable	Acceptance Criteria
M1	Week X	Core Feature A Launch	Complete XX feature, meet XX metrics
M2	Week X	Core Feature B Launch	Complete XX feature, meet XX metrics
M3	Week X	Public Beta Release	Complete full-process validation

Key Metric Targets：

• DAU Target: [X]0,000
• Conversion Rate Target: [X]%
• NPS Target: [X] points

Resource Requirements：

• Frontend: [X] people
• Backend: [X] people
• Design: [X] people

Should the Phase 1 plan be adjusted?

A) The Phase 1 plan is reasonable; continue to Phase 2 B) Milestones need adjustment C) Resource allocation needs adjustment

Confirm phase by phase.

---

Step 4: Identify Key Dependencies and Risks

⚠️ Key Dependencies and Risk Analysis:

External Dependencies：

• Third-party services (payment, SMS, maps, etc.)
• Qualification compliance (licenses, filings, etc.)
• Partner integration

Internal Dependencies：

• Key personnel (core developers, designers)
• Technical infrastructure (database, servers)
• Data infrastructure

Main Risks：

Risk	Probability	Impact	Mitigation Measures
Development delay	High	Milestone delay	Reserve 20% buffer time
Policy changes	Medium	Product direction adjustment	Monitor policy developments
Competitor first-mover advantage	Medium	Market space compressed	Validate quickly, iterate quickly

Are there any other risks that need to be added?

---

Step 5: Output the Product Roadmap

Use the Write tool to create 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

---

Step 6: Completion Prompt

✅ Product roadmap completed!

📄 Generated:docs/03-增长迭代/产品路线图.md

🎯 Suggested next steps:

A) Run /pm-iteration - Create a near-term iteration plan B) Run /pm-risk - Risk control plan C) Run /pm-roadmap - View/update the roadmap

---

Fallback Mechanism

Scenario: Existing roadmap

if [ -f "docs/03-增长迭代/产品路线图.md" ]; then
  echo "⚠️ 检测到已有产品路线图"
fi

Provide options: view/update/replan.

---

Notes

1. The roadmap should focus on "why do it" rather than "how to do it"
2. Every milestone must be measurable
3. Reserve 20% buffer time to handle delays
4. The roadmap is a dynamic document; it is recommended to review and update it monthly

---

Output Quality Comparison

✅ Good Example：

- 有数据引用：「根据 Q4 数据，留存率从 35% 降至 28%」
- 有验证来源：「数据来源：Google Analytics, 2025-12-01」
- 有明确建议：「建议将新手引导步骤从 5 步减少至 3 步」

❌ Bad Example：

- 模糊结论：「数据表明留存率有所下降」
- 无来源：「根据经验，这个功能很重要」
- 没有行动建议：「留存是个问题」

---

Common Pitfalls / Red Flags — STOP

If any of the following occurs, stop immediately and backtrack:

Pitfall	Correct Approach
Drawing conclusions using "should", "probably", or "seems"	Must be based on actual data and verification
Claiming completion without running checks	Verify first, then state
Skipping critical steps due to time pressure	No exceptions; the tighter the time, the stricter you must be
The thought that "this time it should be fine"	Re-verify every time

---

Output Quality Check / Verification Checklist

• Prerequisite dependencies are satisfied (input documents/data have been collected)
• All core steps have been executed
• Output document has been generated to docs/ directory
• Every judgment is supported by data/evidence
• 2-3 follow-up skills have been recommended

⚠️ If any item does not pass → complete it before marking as done.

---