项目规划（分析 + 计划一体化）

本技能用于在开发前产出可执行的“分析计划文件”，既完成需求分析，也完成实施任务编排。

何时使用

• 你要规划一个新功能、模块改造或缺陷修复
• 你希望先澄清需求，再得到可落地的开发任务
• 你需要一份可追踪状态的计划文档，供后续 project-workflow 执行

不适用：仅需直接编码、不需要分析与计划沉淀的超小改动。

核心产出契约（必须遵守）

1. 输出文件：docs/plans/001-feature-name.md（3 位编号 + kebab-case 名称）。
2. 模板来源：./plan-templates/combined-plan-template.md。
3. 文档必须同时包含：
   • 需求分析（目标、边界、风险、隐含需求、验收标准）
   • 实施计划（任务拆解、依赖关系、TDD 执行步骤）
   • 状态管理（整体进度、任务状态总览、执行记录）
4. 每个任务必须可追踪：任务ID、状态、负责人、开始时间、完成时间、阻塞原因。
5. 初始状态统一为：待开始。

工作模式

模式 A：分析驱动（需求不清晰）

触发信号：需求边界模糊、方案分歧明显、验收标准不完整。

执行方式：

• 一次只问一个问题，优先多选题
• 每轮给出 2-3 个方案（含推荐与权衡）
• 分段确认后再进入任务拆解

模式 B：直写计划（需求清晰）

触发信号：目标、范围、验收标准、技术约束都已明确。

执行方式：

• 快速复述需求并确认边界
• 直接输出分析结论与实施计划

执行流程

Step 0：读取上下文

• 读取 docs/README.md
• 读取相关规范（如存在）：docs/specs/PRD.md、docs/specs/SAD.md
• 读取相关模块文档（如存在）：docs/modules/*.md
• 检查既有计划：docs/plans/

Step 1：需求澄清与边界确认

至少明确以下内容：

• 业务目标（为什么做）
• 范围内 / 范围外（做什么 / 不做什么）
• 成功标准（如何判定完成）
• 关键约束（技术、时间、依赖）

Step 2：产出需求分析

在计划文档中输出：

• 需求摘要
• 用户路径 / 核心交互
• 验收标准（AC）草案：改写为可测试条目
• 风险与假设
• 隐含需求清单（权限、空状态、错误状态、性能、兼容性、可观测性）

Step 3：产出实施计划

任务拆解要求：

• 单任务粒度 2-5 分钟
• 明确依赖与执行顺序
• 每个任务包含 TDD 最小闭环：
  • RED：先写失败测试并验证失败
  • GREEN：最小实现并验证通过
  • REFACTOR：重构并回归验证
• 每个任务写清：文件路径、命令、预期结果、完成证据

Step 4：初始化状态管理

计划落地时必须初始化：

• 整体进度（按阶段）
• 任务状态总览表（全部任务默认 待开始）
• 执行记录（写入第一条记录）

Step 5：质量校验（写入前自检）

• KISS：任务描述不绕弯、可直接执行
• YAGNI：删除“可能以后要做”的内容
• DRY：避免重复任务；相同模式合并
• SOLID：任务职责单一、依赖方向清晰
• 可验证：每条 AC 都能映射到测试或验证动作

Step 6：交付与下一步

完成后明确提示：

• 计划文件位置
• 推荐使用 project-workflow 执行
• 如有未决问题，列出“阻塞项 + 建议决策”

对话与澄清规范

• 每次只推进一个关键问题
• 优先多选题，减少沟通成本
• 回答后立即更新分析结论，避免信息漂移
• 当信息不足时，明确标注“假设”而不是臆测

任务编写规则（强约束）

1. 每个任务必须有唯一 任务ID（如 T01、T02）。
2. 每个任务必须标注 依赖任务（无依赖写 无）。
3. 每个任务必须列出：
   • 创建文件
   • 修改文件
   • 测试文件
4. 每个任务必须具备可执行命令与预期输出。
5. 未通过 RED/GREEN/REFACTOR 任一环节，不得标记为 已完成。

与其他技能关系

• project-docs-setup：先补齐项目文档，再做计划。
• project-workflow：按本技能产出的计划执行开发。

建议链路：project-docs-setup → project-planning → project-workflow。