planning-workflow

name	planning-workflow
description	当需要在编码前将想法、功能请求或已确认需求转为含任务、技术设计和测试场景的实现计划时使用。

从想法到实现计划

本文档定义了一个工作流，通过迭代细化单个 Markdown 文档，将模糊想法转化为清晰的实现计划。

核心原则

• 迭代细化: 逐阶段推进，每次更新一个部分
• 用户协作: 每个阶段需要用户明确审查和确认后再继续
• 结构化输出: 所有工作捕获在单一、结构良好的 Markdown 文件中

Markdown 文件结构

管理包含以下 H2 标题的单个 .md 文件：

• ## Idea: 初始概念
• ## Requirements: 功能和非功能需求及验收标准
• ## Tasks: 详细、可操作的工作分解
• ## Design: 高级技术设计和组件结构
• ## Test Cases: 验证实现的场景
• ## Next Steps: 即时行动摘要

工作流阶段

1. 想法 → 需求

• 目标: 将初始想法转化为清晰、可验证的需求
• 流程:
  1. 在 ## Idea 部分捕获用户想法
  2. 提出澄清问题解决歧义
  3. 在 ## Requirements 下起草具有 Given-When-Then 验收标准的具体需求
  4. 请求用户审查和确认

2. 需求 → 任务

• 目标: 将需求分解为细粒度、可操作的任务列表
• 流程:
  1. 分析已批准的需求
  2. 按以下原则在 ## Tasks 部分分解：
     • MECE: 任务必须相互独立且完全穷尽
     • 明确目标与交付物: 每个子任务必须有精确定义的目标和可验证的预期交付物
     • 可管理规模: 将任务分解为足够小的块
     • 优先级: 考虑业务价值、依赖关系和风险
     • 独立性: 争取可独立工作和测试的子任务
     • 可验证性: 设计可清晰验证完成的子任务
  3. 请求用户审查和确认

3. 任务 → 设计

• 目标: 创建技术设计规范
• 流程:
  1. 分析已批准的任务
  2. 在 ## Design 部分提出设计，包括类、方法和关系（鼓励使用 Mermaid 图表）
  3. 确保设计考虑现有架构和质量标准
  4. 请求用户审查和确认

4. 设计 → 测试用例

• 目标: 定义全面的测试用例集
• 流程:
  1. 分析已批准的设计
  2. 在 ## Test Cases 下定义测试用例（正面、负面、边界）
  3. 确保需求的完整覆盖
  4. 在 ## Next Steps 添加实现建议
  5. 请求用户审查和确认

---

执行指导（规划分析师模式）

当进行规划任务时，按以下流程执行：

阶段转换引导

想法 → 需求 → 任务 → 设计 → 测试用例
      ↑        ↑       ↑        ↑
    澄清问题  MECE分解  架构设计  覆盖验证

执行检查清单

阶段	关键动作	用户交互
想法→需求	提问澄清歧义	等待确认
需求→任务	MECE 分解	等待确认
任务→设计	绘制架构图	等待确认
设计→测试	定义验证场景	等待确认

触发条件

• 用户提出新想法或功能请求
• 需求分析任务
• 项目规划讨论
• 技术方案设计

关键原则

• 用户协作: 每个阶段必须等待用户确认
• 单一文档: 所有产出集中在一个 Markdown 文件
• 迭代细化: 允许回退修正，但保持结构化进展
• MECE 分解: 任务必须相互独立、完全穷尽