Menu
制定开发计划。阅读前置文档 + 调研技术方案 + 复用开源项目，输出分阶段可执行的 Dev-Plan.md。
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
构建验证、版本管理与发布上线。多轮确认发布目标与推送路径后执行门禁与发布，写入状态与 release notes。用户提到发布、上线、deploy、打 tag、发版、merge 到 main、推远程、构建生产包、创建 PR 时，即使未说 release 也必须使用本 skill。
技术架构设计。调研技术方案、评估开源项目、输出架构决策记录，写入 Tech-Arch.md。在 dev-planner 之前调用。
设计执行。基于 Design-Brief.md 产出原型、设计稿或设计系统。支持 Figma、Pencil、HTML/CSS 原型等多种输出方式。
需求收集与问题澄清。新建或迭代 PRD，通过交互式澄清生成结构化产品需求文档。
系统化调试修复 Bug。五阶段：收集证据→重现用例→分析(含根因归因)→假设→修复→进化记录。支持触发 code-review 和 feedback-writer。
代码审查和质量检查。调度 code-reviewer sub-agent 审查代码，检查是否符合计划和编码标准。
| 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 — 追加规划变更记录