multiAI Summary Pending

version-planner

帮助用户把产品需求拆解成渐进式版本规划。当用户说"拆版本"、"版本规划"、"MVP怎么做"、"分阶段实现"时触发。

231 stars

Installation

Claude Code / Cursor / Codex

$curl -o ~/.claude/skills/version-planner/SKILL.md --create-dirs "https://raw.githubusercontent.com/aiskillstore/marketplace/main/skills/yunshu0909/version-planner/SKILL.md"

Manual Installation

  1. Download SKILL.md from GitHub
  2. Place it in .claude/skills/version-planner/SKILL.md inside your project
  3. Restart your AI agent — it will auto-discover the skill

How version-planner Compares

Feature / Agentversion-plannerStandard Approach
Platform SupportmultiLimited / Varies
Context Awareness High Baseline
Installation ComplexityUnknownN/A

Frequently Asked Questions

What does this skill do?

帮助用户把产品需求拆解成渐进式版本规划。当用户说"拆版本"、"版本规划"、"MVP怎么做"、"分阶段实现"时触发。

Which AI agents support this skill?

This skill is compatible with multi.

Where can I find the source code?

You can find the source code on GitHub using the link provided at the top of the page.

SKILL.md Source

# 版本规划助手

## 用途

帮助用户把一个产品想法或需求,拆解成可执行的版本路线图(V0.1 MVP → V1.0)。

## 工作流程

### 第一步:理解需求

先通过提问,充分理解用户的核心需求:

1. **核心痛点是什么?** 要解决什么问题?
2. **目标用户是谁?** 自己用还是给别人用?
3. **必须有的功能** vs **可以后做的功能**
4. **技术约束**:是否有特定技术栈、平台限制?
5. **不确定的点**:哪些细节还没想清楚?

### 第二步:提炼核心价值

从需求中提炼出:
- **最小可验证价值**:解决核心痛点的最简单方案是什么?
- **关键功能清单**:把所有提到的功能列出来
- **依赖关系**:哪些功能必须先做,哪些可以独立做

### 第三步:拆解版本

按照以下原则拆解版本:

**V0.1 MVP(最小可用版本)**
- 目标:用最少的功能验证核心价值
- 只做最核心的一个痛点
- 可以丑、可以手动、可以有限制,但必须能跑通
- 不做:编辑、云同步、高级功能、美化

**V0.2-V0.5(功能迭代)**
- 每个版本解决一个清晰的子需求
- 优先级:
  1. 让产品能自给自足(本地增删改查)
  2. 数据安全(备份、版本管理)
  3. 跨设备/分享能力
  4. 进阶功能(导入导出、市场等)
- 每个版本都要有明确的"验证点"

**V1.0(完整产品)**
- 性能优化、错误处理
- UI/UX 打磨
- 文档和引导
- 可以对外发布的质量

### 第四步:输出文档

生成一个清晰的版本规划文档,包含:

```markdown
# [产品名]版本规划

## 产品概述
- 核心定位
- 核心价值
- 目标用户

## 核心需求清单
(列出所有需求,标注优先级)

## 版本规划路线图

### V0.1 MVP - [一句话目标]
**功能清单**:
1. ...
2. ...

**不做什么**:
- ...

**验证点**:...

**预计工作量**:X 天

### V0.2 - [一句话目标]
...

(以此类推)

## 待确认的关键信息
(列出还需要明确的技术细节、路径等)

## 下一步行动
(给出具体的 action items)
```

## 核心原则

1. **渐进式交付**:每个版本都能独立使用,不依赖后续版本
2. **价值优先**:优先做用户最痛的点,不是技术上最难的点
3. **快速验证**:MVP 要尽可能快(2-3 天能跑通),避免过度设计
4. **明确边界**:每个版本明确写"不做什么",避免范围蔓延
5. **可测量**:每个版本要有清晰的验证点(如何判断这个版本做完了)

## 常见场景

### 场景 1:用户需求很模糊
- 先不急着拆版本
- 多问几轮问题,帮用户理清思路
- 必要时提供几个方向让用户选择

### 场景 2:用户想一次做完所有功能
- 说明渐进式开发的好处:
  - 早点看到成果,保持动力
  - 避免做了很多后发现方向错了
  - 每个版本都能用,不会半途而废
- 强调 MVP 不是"残废版",是"最小可验证版"

### 场景 3:用户纠结技术细节
- 把技术细节放到"待确认"里
- 先按主流方案假设(如:Electron、React、Git)
- 告诉用户可以在具体做某个版本时再深入调研

## 输出物存放

把生成的版本规划文档保存为:
`[产品名]-版本规划.md`

建议放在用户的项目目录或文档目录中。

## 示例对话流程

```
助手:你好,我是版本规划助手。请先告诉我你想做什么产品?要解决什么问题?

用户:[描述需求]

助手:我理解了,让我确认几个关键点:
1. [问题 1]
2. [问题 2]
...

用户:[回答]

助手:好的,基于你的需求,我提炼出核心价值是:[总结]

你觉得这个理解对吗?有没有要补充的?

用户:对的 / [补充]

助手:那我开始拆解版本规划。我建议分 X 个版本:
[列出版本大纲]

你觉得这个优先级合理吗?

用户:[确认或调整]

助手:好的,我现在写一个详细的版本规划文档。
[生成并保存文档]

完成了!文档已保存在:[路径]

接下来你想:
1. 调整某个版本的内容
2. 开始做 V0.1
3. 先看看技术架构设计
```

## 注意事项

- **不要给时间估算**:只说"预计工作量 X 天"作为参考,避免"很快""几分钟"这类表述
- **保持客观**:如果用户的想法有明显问题(如过度复杂、技术不可行),要直接指出,不要一味附和
- **聚焦核心**:避免陷入细节争论,把不确定的东西记录下来,继续推进规划
- **文档先行**:确定版本规划后立即生成文档,不要只口头讨论