cxb-task-plan
从确认后的方案生成可执行任务制品。
它做什么
cxb-task-plan 的作用是把设计意图转成执行状态。它是“已评审的方案”和“可恢复、可自动推进的任务流水线”之间的桥梁。
实际会做三件事：
- 确保方案本身已经足够可靠
- 把方案拆成适合执行的步骤
- 写出
cxb-task-run可以安全推进的状态文件
工作流
1. 初始化上下文
生成制品之前，Claude 会先读取仓库：
- 项目结构
- 主要语言与框架
- 测试方式
- 是否存在需要额外调研的陌生依赖
这样可以避免“通用型方案”被直接转成不现实的执行步骤。
2. 运行协作规划
cxb-task-plan 通常会先调用 cxb-plan，确保任务从已批准方案开始，而不是从含糊提示开始。
3. 向用户确认
Claude 会先总结：
- 目标
- 主要步骤
- 验收标准
这是收紧范围的最好时机，避免带着模糊要求进入执行阶段。
4. 生成 .curdx/ 制品
| 文件 | 用途 |
|---|---|
.curdx/state.json | 机器可读的执行状态与重试信息 |
.curdx/todo.md | 面向人的步骤列表与状态标记 |
.curdx/plan_log.md | 决策、变更、审查结果的持续日志 |
一个合理的 todo.md 通常具备：
- 粗粒度步骤
- 明确顺序
- 每一步都能独立审查
5. 可选进入执行
生成任务制品后，可以立刻交给 cxb-task-run 推进，也可以稍后恢复。
示例
如果批准方案是“为管理员操作添加审计日志”，cxb-task-plan 可能生成如下步骤：
- 增加审计事件模型与存储接口
- 在管理员写路径中接入日志
- 为支持人员补充查询能力
- 增加测试与文档
这类步骤是“执行级”的，而不是“实现微步骤”，不会细到“加一个字段”或“改一个函数名”。
最佳实践
- 步骤要足够大，值得执行；也要足够小，便于审查。
- 中等功能通常控制在 3 到 7 步最合理。
- 高风险任务应把测试或验证显式列为步骤。
- 如果用户确认仍然模糊，就不要急着生成执行制品。
适合触发 cxb-task-plan 的请求
- “把这个评审通过的方案转换成可恢复的任务列表。”
- “为这个功能拆解可执行步骤，并准备 AutoFlow 状态。”
- “先生成
.curdx任务制品，等我确认后再执行。”