Menu
Le prompt qui vérifie d'abord la source est sélectionné par défaut. Vous pouvez passer à une commande directe ou télécharger une copie locale.
Lisez SKILL.md et les fichiers associés affichés par SkillsMP avant de décider de l'installer.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
npx skills add https://github.com/Herxinsasa/Product-Manager --skill dev-plannerLa commande reste sur une seule ligne. Faites défiler horizontalement pour la vérifier avant de la copier.
Vous préférez une copie locale ? Téléchargez les fichiers actuellement disponibles dans SkillsMP.
Affichage de SKILL.md
Basé sur la classification professionnelle SOC
| name | dev-planner |
| description | 制定开发计划。阅读前置文档 + 调研技术方案 + 复用开源项目，输出分阶段可执行的 Dev-Plan.md。 |
基于 Tech-Arch.md 中的技术架构方案，拆分可执行的开发任务，制定分阶段开发计划。输出到 Dev-Plan.md。
此 skill 不负责技术选型或架构设计。 那是 tech-architect 的工作。如果 Tech-Arch.md 不存在，引导用户先走技术架构流程。
不做重复造轮子： 复用清单已在 Tech-Arch.md 中列出，规划时直接引用，不重新调研。
计划服务于执行： 任务拆分粒度必须细到 dev-builder 能直接拿去派给 implementer 执行，不能停留在「实现用户系统」这种模糊描述。
技术方案是输入不是输出： 技术选型和架构已由 tech-architect 完成，dev-planner 直接引用 Tech-Arch.md 中的结论，不重新调研。
Tech-Arch.md 必须已存在（技术架构已确定）Product-Spec.md 必须已存在Design-Brief.md 如已存在则纳入参考tech-architect检查 Dev-Plan.md 是否已存在。
情况 A — 不存在： 进入新建模式，完整执行 Step 1-5。
情况 B — 已存在： 进入迭代模式：
按顺序完整阅读以下文档，提取关键信息：
| 文档 | 提取内容 |
|---|---|
Tech-Arch.md | 技术栈选型、架构模式、目录结构设计、复用项目清单、ADR 中的约束条件 |
Product-Spec.md | MVP 功能列表及验收标准、优先级、后续迭代功能 |
Design-Brief.md（如有） | 配色/组件规范、模块 UE 布局——影响前端任务的拆分粒度 |
阅读后心里确认：
技术方案已由 Tech-Arch.md 提供，直接进入任务拆分。
用户拖入 .log 文件后，3 秒内看到解析结果列表实现日志导入功能阶段 0：项目脚手架（1-2 个任务）
└── 项目初始化、构建配置、开发环境
阶段 1：核心基础设施（2-4 个任务）
└── 路由、状态管理、API 层、数据库 schema、认证等
阶段 2：MVP 功能实现（每个功能 1-3 个任务）
└── 按优先级排序，每个功能独立可测试
阶段 3：集成与联调（2-3 个任务）
└── 功能串联、数据流贯通、端到端流程
阶段 4：设计还原（2-4 个任务，如果有 Design-Brief）
└── 配色变量注入、组件风格统一、响应式适配、动效
阶段 5：测试与收尾（2-3 个任务）
└── 核心流程测试、构建验证、部署配置
输出 Dev-Plan.md 前，呈现计划摘要请用户确认：
## 开发计划确认
**技术栈**：<技术栈>
**可复用项目**：<N> 个，可省 <X> 个实现任务
**总阶段数**：<N> 个
**总任务数**：<N> 个（每个任务 = implementer 单次执行单元）
**预估 AI 执行轮次**：约 <N> 轮（含 code-review + 修复循环）
**阶段概览**：
阶段 0：项目脚手架（<N> 个任务）
阶段 1：核心基础设施（<N> 个任务）
阶段 2：MVP 功能（<N> 个任务）
...
以上计划是否合理？任务顺序需要调整吗？
用户确认后写入 Dev-Plan.md。
# <产品名称> — 开发计划
## 1. 技术方案（引用）
> 详见 [Tech-Arch.md](./Tech-Arch.md)
| 层级 | 选型 | 版本 |
|------|------|------|
| 前端框架 | | |
| UI 组件库 | | |
| 状态管理 | | |
| ... | | |
架构图、ADR、复用/自研清单详见 Tech-Arch.md。
## 2. 阶段划分
### 阶段 0：项目脚手架
- [ ] **任务 0.1**：<任务名>
- 描述：<做什么>
- 产出：<文件列表>
- 设计参照：Design-Brief.md §<章节号>；若有设计交付物，引用 design/ 下具体路径
- 验收：<验收标准>
- 依赖：无
### 阶段 1：核心基础设施
- [ ] **任务 1.1**：<任务名>
- 描述：<做什么>
- 产出：<文件列表>
- 设计参照：Design-Brief.md §<章节号>；若有设计交付物，引用 design/ 下具体路径
- 验收：<验收标准>
- 依赖：任务 0.1
### 阶段 2：MVP 功能实现
- [ ] **任务 2.1**：<任务名>
...
### 阶段 3：集成与联调
...
### 阶段 4：设计还原（如有 Design-Brief）
...
### 阶段 5：测试与收尾
...
## 3. 风险与应对
| 风险 | 影响 | 应对 |
|------|------|------|
| | | |
## 4. 里程碑
| 阶段 | 里程碑描述 | 可验证内容 |
|------|-----------|-----------|
| 阶段 1 结束 | 项目能启动，基础框架就绪 | 浏览器打开看到页面 |
| 阶段 2 结束 | 核心功能可用 | <核心功能>可独立操作 |
| ... | | |
追加到 Product-Spec-CHANGELOG.md：
v<当前版本> → 新增 → 制定开发计划：技术栈 <...>，<N> 个阶段 <M> 个任务，可复用 <K> 个项目进度 checkpoint：更新 .claude/progress.json：
current_phase: "development"documents.Dev-Plan.md：exists: truemilestones 追加「开发计划已制定： 阶段 任务」开发计划已写入 Dev-Plan.md。接下来：
- A. 开始编码 — 调用 dev-builder 按计划逐阶段开发
- B. 调整计划 — 还有什么要修改的
Dev-Plan.md — 完整的分阶段可执行开发计划（技术方案 + 任务拆分 + 里程碑）Product-Spec-CHANGELOG.md — 追加规划变更记录