[任务] 生成模式：读取 Product-Spec.md（和 Design-Brief.md，如有），分析功能依赖关系，WebSearch 验证技术选型，输出分阶段开发计划 DEV-PLAN.md。

**迭代模式**：当 Product Spec 变更后，分析变更影响范围，更新 DEV-PLAN.md 中的 Phase 划分和文件清单。已完成的 Phase（标记 ✅）不动。

[依赖检测] Skill 启动时第一步自动执行：

必需：
- Product-Spec.md → 缺失则提示先调用 /product-spec-builder

可选（降级模式）：
- Design-Brief.md → 缺失则标记"无设计规范模式"，视觉相关细节标注 [待 Design Brief 补充]
- 设计工具 MCP → 未连接或无文件则仅依据文字描述，标记"无设计稿模式"
- 已有项目代码 → 有则扫描现有结构作为约束，进入迭代模式

[第一性原则] 可验证原则：每个 Phase 完成后必须能编译、能运行、能看到效果。不允许"写一堆代码但什么都跑不起来"的 Phase。

**依赖正序原则**：地基先打，房子后盖。基础设施（项目骨架、数据库、路由）永远排在业务功能前面。功能之间有依赖关系的，被依赖方先做。

**联网优先原则**：不靠过期记忆，靠实时信息。
- 技术栈选型 → 先 WebSearch 确认框架最新稳定版本、已知问题、推荐搭配
- 关键依赖 → 先 WebSearch 确认 API 兼容性、版本号、是否有 breaking changes
- 不确定的技术方案 → 搜了再定，不凭过期记忆做架构决策

**粒度适中原则**：Phase 太大做不完，太小管理成本高。一个 Phase 对应一个可独立验收的功能单元，通常 1-3 个核心交付物。

**文件路径明确原则**：每个 Phase 必须列出要创建或修改的具体文件路径。"实现聊天功能"不是计划，"创建 src/components/views/chat-view.tsx 和 src/hooks/use-chat.ts" 才是计划。

**无占位符原则**：Plan 里每一个字都要具体到任何人拿到这份 Plan 都能直接开工。
- 不允许：TBD、TODO、"待补充"、"待确定"、"implement later"
- 不允许："类似 Task N"——重复具体内容，不引用
- 不允许："添加适当的错误处理"——指明处理什么错误、怎么处理
- 不允许："实现相关功能"——列出具体功能名称和行为
- 每个 Task 描述必须完整到一个没有项目上下文的工程师也能读懂并执行

必需： - Product-Spec.md → 缺失则提示先调用 /product-spec-builder 可选（降级模式）： - Design-Brief.md → 缺失则标记"无设计规范模式"，视觉相关细节标注 [待 Design Brief 补充] - 设计工具 MCP → 未连接或无文件则仅依据文字描述，标记"无设计稿模式" - 已有项目代码 → 有则扫描现有结构作为约束，进入迭代模式

**依赖正序原则**：地基先打，房子后盖。基础设施（项目骨架、数据库、路由）永远排在业务功能前面。功能之间有依赖关系的，被依赖方先做。 **联网优先原则**：不靠过期记忆，靠实时信息。 - 技术栈选型 → 先 WebSearch 确认框架最新稳定版本、已知问题、推荐搭配 - 关键依赖 → 先 WebSearch 确认 API 兼容性、版本号、是否有 breaking changes - 不确定的技术方案 → 搜了再定，不凭过期记忆做架构决策 **粒度适中原则**：Phase 太大做不完，太小管理成本高。一个 Phase 对应一个可独立验收的功能单元，通常 1-3 个核心交付物。 **文件路径明确原则**：每个 Phase 必须列出要创建或修改的具体文件路径。"实现聊天功能"不是计划，"创建 src/components/views/chat-view.tsx 和 src/hooks/use-chat.ts" 才是计划。 **无占位符原则**：Plan 里每一个字都要具体到任何人拿到这份 Plan 都能直接开工。 - 不允许：TBD、TODO、"待补充"、"待确定"、"implement later" - 不允许："类似 Task N"——重复具体内容，不引用 - 不允许："添加适当的错误处理"——指明处理什么错误、怎么处理 - 不允许："实现相关功能"——列出具体功能名称和行为 - 每个 Task 描述必须完整到一个没有项目上下文的工程师也能读懂并执行

**必须分析**（没有这些，DEV-PLAN 就是空中楼阁）： - 技术栈确定：从 Spec 的技术方向章节提取推荐技术栈，WebSearch 验证框架版本、兼容性、已知问题。如 Spec 只写了方向（如"Web 应用"）没写具体栈，则根据项目类型推荐并确认。 - 确认项：框架 + 版本号、UI 方案、数据库方案、包管理器、部署目标 - WebSearch 重点：框架最新稳定版、关键依赖兼容性、社区推荐搭配 - 如有多个合理选项 → 给用户 2-3 个方案 + 优劣对比，让用户选 - Phase 拆分：将 Spec 中的功能需求按依赖关系和复杂度分解为有序的 Phase 序列。每个 Phase 是一个可独立验收的功能单元。 - 拆分依据：功能依赖关系（A 依赖 B → B 先做）、技术基础设施放最前、核心功能优先于辅助功能 - 粒度标准：一个 Phase 通常包含 1-3 个核心交付物 - 每个 Phase 的交付清单：每个 Phase 必须明确交付什么。用动词开头，描述用户可感知的功能。 - 格式："用户能做什么 → 系统做什么"或"完成 XX 基础设施搭建" - 每个 Phase 的关键文件：每个 Phase 必须列出将要创建或修改的具体文件路径。 - 对新项目：根据技术栈的约定推导目录结构（如 Next.js 的 src/app/api/、src/components/ 等） - 对已有项目：扫描现有代码结构作为基础 - 功能依赖图：识别功能之间的依赖关系，确保 Phase 排序不违反依赖。 - 例：聊天 UI 依赖消息数据库 → 数据库必须在聊天 UI 之前 - 例：IM Bridge 依赖 Agent 引擎 → Agent 引擎必须在 IM 之前 **尽量分析**（有这些，Plan 更落地）： - 数据库设计：如项目需要数据库，梳理所有数据表、所属 Phase、用途。 - 格式：表名 + 首次创建的 Phase + 用途说明 - 每个 Phase 的验收标准：每个 Phase 完成时如何验证。 - 最低标准：能编译、能启动、新功能可用 - 推荐标准：能编译 + 能启动 + 新功能可用 + 现有功能未破坏 - 已知风险与限制：标注某些 Phase 中预期会有的技术风险或已知限制。 - 例："Phase 4 只实现 UI 配置界面，IM 实际连接引擎在 Phase 10" **不需要分析**（交给 dev-builder 决定）： - 具体的代码实现细节（函数签名、类接口） - 具体的 CSS 样式方案 - 测试用例设计 - Git 分支策略

第一步：依赖检测执行 [依赖检测] 第二步：加载 Product Spec 读取 Product-Spec.md 提取：产品类型、核心功能列表、辅助功能列表、AI 能力需求、技术方向、UI 布局结构、数据存储方式检查 Product-Spec.md 中是否包含 [待补充] 标记。如有，列出涉及的条目并提示用户先补充或确认可以跳过第三步：加载 Design Brief（如有）读取 Design-Brief.md 提取：核心页面列表、视觉方向（影响组件拆分粒度）第四步：加载设计稿（如有）检查设计工具 MCP 是否连接如有 → 通过设计工具读取设计稿，提取： - 所有页面和变体的完整清单 - 各页面的组件构成和布局结构 - 具体的交互元素和状态变体 - 页面之间的跳转关系 - 可复用组件列表设计稿存在时，Phase 拆分和关键文件规划必须以设计稿的实际页面结构为准。设计稿中的页面数量、组件数量直接决定 Phase 的工作量和文件清单，不能只看 Spec 文字描述。如无 → 跳过，仅依据 Spec 和 Design Brief 的文字描述第五步：扫描已有代码（如有）如果项目目录中已有代码 → 扫描目录结构，识别技术栈和已实现的功能标记为已有代码约束，避免 Plan 与现有结构冲突 [技术验证阶段] 目的：确定并验证技术栈第一步：提取技术方向从 Spec 的技术方向章节提取推荐的技术栈如 Spec 无明确技术栈 → 根据项目类型推荐： - Web（纯前端）→ React + Vite + TypeScript + Tailwind - Web（全栈）→ Next.js + TypeScript + Tailwind - Desktop → Electron + Next.js + TypeScript + Tailwind - CLI → Node.js + TypeScript + Commander - Mobile → React Native / Expo 第二步：WebSearch 验证对照 [分析维度清单] 中的"技术栈确定"维度运用 [分析策略] 中的"WebSearch 验证法" 验证框架版本、关键依赖兼容性、已知问题第三步：确认技术栈如有多个合理选项 → 向用户展示 2-3 个方案 + 优劣对比，让用户选如 Spec 技术方向明确且验证通过 → 直接确认，不需要问用户输出确认的技术栈表 [分析阶段] 目的：分析功能依赖关系，拆分 Phase 第一步：功能拆解将 Spec 中的功能需求逐条列出如有设计稿 → 以设计稿的页面结构为准，逐页面确认涉及的功能和组件。设计稿中的页面数量和组件构成直接决定 Phase 的文件清单如无设计稿 → 依据 Spec 和 Design Brief 的文字描述推导页面结构标注每个功能的：类型、依赖的其他功能、涉及的数据表、涉及的页面和组件第二步：依赖图构建运用 [分析策略] 中的"依赖图构建法" 构建功能依赖图，识别先后顺序第三步：Phase 拆分运用 [分析策略] 中的"洋葱剥皮法"和"风险前置法" 将功能按依赖顺序和优先级分组为 Phase 运用"粒度校准法"检查每个 Phase 的粒度第四步：充足度判断对照 [信息充足度判断] 「必须满足」全部达成 → 进入输出阶段有疑问 → 向用户确认后继续 [输出阶段] 目的：生成 DEV-PLAN.md 文件第一步：加载模板读取 templates/dev-plan-template.md 第二步：填充内容按模板结构填写： - Phase 列表（编号 + 功能名 + 交付清单 + 关键文件 + 验收标准） - 技术栈表 - 数据库表汇总（如有） - 开发规则第三步：自检运用 [分析策略] 中的"粒度校准法"再次检查确认 Spec 中每个核心功能都有对应 Phase 确认 Phase 顺序不违反依赖关系无占位符检查：扫描输出内容中是否包含 TBD、TODO、待补充、待确定、"类似 Phase/Task N"等占位符，如有则替换为具体内容第四步：输出文件保存为 DEV-PLAN.md 第五步：引导下一步 "✅ DEV-PLAN.md 已生成！文件：DEV-PLAN.md 共 N 个 Phase，覆盖 Spec 中的全部 X 个功能。接下来： - 调用 /dev-builder 按 Phase 开始开发 - 或先调用 /design-brief-builder 确定视觉方向（如还没做） - 想调整 Phase 粒度或顺序？直接告诉我。"

Dev Planner

Dev Planner

Taskflow Inbox Triage

Accessibility

Open a Pull Request

Investor Materials

Continuous Agent Loop

Configure Ecc