task-planning

Task Planning

规划不是猜测，是分析需求 → 定义蓝图 → 拆解可执行任务 → 建立可验证的验收标准。本技能与 [[task-traceability]] 协作，确保每次规划产出清晰、可执行、可追溯——每个任务都可追溯到具体需求。

---

何时触发

• Leader 分配新的需求/目标给 Planner
• 用户说"分析一下这个需求"、"拆解任务"、"制定执行计划"
• 新的工作周期开始，需要产出任务列表
• 现有蓝图需要修订或补充

---

规划六步法

按顺序执行，每一步通过才进入下一步。任一步产出不清晰 → 回退澄清。

1. 读取需求上下文

定位并理解需求来源：

• 如果是 Leader 通过 orchestrator 分配的需求，通过 claude-orchestrator get-context --key <需求key> 获取
• 如果是本地文档（如 docs/pm/YYYY-MM-DD/），读取完整内容
• 如果是代码库需求（如 Issue、PR 描述），读取相关文档和代码

提取关键信息：

• 业务目标和背景
• 约束条件和边界
• 期望的交付标准和截止时间

2. 定义任务蓝图

输出蓝图文档，包含以下要素：

# 任务蓝图：[目标名称]

> Planner | YYYY-MM-DD | 版本 v1

## 目标

（一句话描述要达成什么）

## 背景

（为什么需要做这个，解决什么问题）

## 范围与非范围

**范围内：**
- 具体要做的事项 1
- 具体要做的事项 2

**不在范围内：**
- 明确不做的事项 1

## 约束条件

- 技术约束（如必须兼容 Node.js 18+）
- 时间约束
- 依赖约束（如依赖外部服务 X 先就绪）

## 成功定义

（可验证的成功标准，不是抽象描述）
- 标准 1：所有单元测试通过，覆盖率 ≥ X%
- 标准 2：UI 交互流程可在浏览器中完成
- ...

3. 拆解可执行任务

将蓝图拆解为独立的任务项。每个任务必须满足：

• 可独立执行：Builder 无需频繁跨任务上下文切换
• 可验证：有明确的验收标准（测试命令、UI 检查点、文件路径等）
• 有产出物：代码变更、测试报告、截图、文档等

## 任务清单

| # | 任务 | 类型 | 验收标准 | 预估 | 依赖 |
|---|------|------|---------|------|------|
| 1 | 实现 XXX 模块 | build | `npm test -- XXX` 全部通过 | 2h | - |
| 2 | 编写 YYY 集成测试 | build | `npm test -- YYY` 覆盖 3 个场景 | 1h | #1 |
| 3 | 验证 ZZZ 边界情况 | verify | 运行边界测试套件，0 失败 | 0.5h | #2 |
| 4 | 审查整体方案一致性 | review | 审查报告无 P0/P1 问题 | 0.5h | #2, #3 |
| 5 | 验收最终交付物 | accept | 对照验收标准逐项通过 | 0.5h | #4 |

任务类型对应责任链环节：plan / build / verify / review / accept。

依赖字段确保责任链顺序：P → B → V → R → A。

4. 推入任务队列

通过 orchestrator 将任务推入队列，指定每个任务的责任链环节：

# Build 任务
claude-orchestrator push-task \
  --title "实现 XXX 模块" \
  --link build \
  --priority 0

# Verify 任务
claude-orchestrator push-task \
  --title "验证 ZZZ 边界情况" \
  --link verify \
  --priority 1

# Review 任务
claude-orchestrator push-task \
  --title "审查整体方案一致性" \
  --link review \
  --priority 1

# Accept 任务
claude-orchestrator push-task \
  --title "验收最终交付物" \
  --link accept \
  --priority 1

优先级建议：plan 和下游瓶颈任务用 0（HIGH），其余用 1（MEDIUM）。