Task Planning（任务规划）

Purpose

把一个多步骤需求变成一份可执行的任务计划：任务清单 + 影响范围 + 每步验证方式， 并落实文件变更 / 数据流 / 测试方案三要素。产出的是计划，不是代码实现。

When to Use

• 当接到多步骤需求或新功能开发，预计改动跨多个文件 / 模块时
• 当需求与现有实现的关系不明，需要先读代码确认改动点时
• 当用户要求「先给方案 / 拆任务 / 评估工作量」再动手时
• 当同一需求要拆给多个会话或多个人并行执行，需要一份共同依据时

When NOT to Use

• 单文件小改动（改一个函数、一处样式）：直接实现，结束前用 verification 收尾
• 已有 issue 或设计文档列出了明确任务清单：按文档执行，不重复规划
• 定位报错根因：改用 debugging-and-error-recovery，定位后再回来规划修复
• 测试先行的开发循环：改用 test-driven-development
• 贯穿数据库到 UI 的全栈功能开发：改用 feature-development（其七步顺序更具体）

Inputs

• 需求描述（issue、对话或设计文档）：缺失或含关键歧义时先问清目标与验收标准，不自行假设
• 仓库读权限（现有实现与 Git 状态）：缺失时报告并停止，不凭记忆规划
• 项目入口资料（CLAUDE.md、package.json、目录结构）：缺失时按常规布局探索，并把结论记为假设

Workflow

1. Inspect

• 读 CLAUDE.md / README 拿项目约定；读 package.json 的 scripts 与依赖，确认可用的检查命令
• git status + git log --oneline -10：确认当前分支、未提交改动与近期改动风格
• 找相似实现：按关键词检索同类组件、API、类型与测试，记录 1-3 个可参照的 文件:行号
• 列出可能受影响的模块及其现有约束（命名、分层、状态管理、测试组织方式）

2. Plan

• 把需求拆成有序任务：每条以动词开头，附一条可判定的完成标准
• 每个任务标注影响范围：改哪些文件、哪些调用方受影响
• 每个任务指定验证方式，具体到命令形态（如 npx vitest run src/foo、npx tsc --noEmit）
• 发现歧义停下先问；不在计划里替用户决定实现路径

3. Implement

• 本步产出计划本身，不写业务代码：文件变更清单（新增 / 修改 / 删除）、 数据流（输入 → 处理 → 输出 → 存储）、测试方案（新增哪些用例、覆盖哪些路径）
• 计划默认落在回复正文；仅当用户要求时创建计划文件，用编号 + 复选框表达，保持可勾选、可被后续任务引用

4. Verify

• 逐条对照需求：每个验收点都有对应任务，无遗漏
• 每个任务都有影响范围与验证方式，且粒度可独立验证
• 用检索复核影响范围：被改符号的全部引用处都已列入计划

Rules

• 必须先读现有实现再拆任务，禁止规划不存在的接口或不存在的文件路径
• 禁止把「实现功能」写成一个黑盒任务；最小任务粒度 = 一次可独立验证的改动
• 禁止无关重构：计划中的每一项都必须能追溯到需求原文
• 关键歧义必须先问；用户未答复前不产出最终计划
• 计划不得引入需求之外的架构或依赖变更

Common Failure Modes

Common Rationalizations

Verification

• 计划中的每个文件路径 → 用 ls / Read 确认存在，或明确标注为「新增」
• 每个被改符号 → 检索其引用处，证明影响范围覆盖完整
• 计划三要素 → 文件变更 / 数据流 / 测试方案各至少一节，缺一不算完成

Exit Criteria

• 任务有序、逐条可独立验证，且每条带完成标准
• 文件变更 / 数据流 / 测试方案三要素齐备
• 每个任务标注影响范围与验证方式
• 关键歧义已问清，或已作为阻塞项显式列出