将大任务拆分为多个子任务,每个子任务的 requirements 文档控制在 200 行以内。当用户想要:1) 拆分一个大任务 2) 将任务分解为多个小任务 3) 执行 /an-task-split 命令 4) 提到"任务拆分"、"分解任务"、"大任务"、"拆分"等关键词时触发此技能。
将大任务拆分为多个可独立推进的子任务,每个子任务的 requirements 控制在 200 行以内。
你是该领域的业务专家,具备丰富的产品和技术经验。你需要以专家视角理解用户任务,识别自然的业务边界和功能边界,做出合理的拆分决策。
用户可通过以下方式提供 raw-input:
workspace/xxx/raw-input/task.md)raw-input → split-plan
目标:保存用户的原始大任务描述,不做加工。
行为:
workspace/{YYYYMMDD}__{feature-name}/workspace/{YYYYMMDD}__{feature-name}/raw-input/task.md产出物:
workspace/{YYYYMMDD}__{feature-name}/raw-input/
└── task.md # 原始输入内容
目标:以业务专家视角分析任务,产出拆分方案。
前置:阅读以下文档获取上下文:
background/product.md — 产品定位background/domains.md — 领域模型background/features.md — 功能状态行为:
产出物:workspace/{YYYYMMDD}__{feature-name}/split-plan.md
# {任务名称} 拆分方案
## 任务理解
{以业务专家视角,阐述对任务全貌的理解}
## 拆分依据
{从哪些维度进行了拆分,为什么选择这些边界}
## 拆分概览
| 序号 | 子任务名称 | 核心目标 | 预估行数 | 依赖 |
|------|-----------|---------|---------|------|
| 1 | sub-1 | {一句话} | ~N行 | - |
| 2 | sub-2 | {一句话} | ~N行 | sub-1 |
## 依赖关系
{子任务之间的依赖拓扑描述}
## 子任务定义
### sub-1: {名称}
- **目标**: {一句话描述}
- **核心场景**: {关键业务场景}
- **关键验收标准**: {最核心的 AC 要点}
- **预估行数**: ~N行
- **工作区**: workspace/{YYYYMMDD}__{sub-1}/
### sub-2: {名称}
...
## 执行顺序建议
1. sub-1 → 2. sub-2 → ...
检查点:向用户展示拆分方案,等待用户审核确认。用户可能:
确认拆分方案后,更新项目根 CLAUDE.md 的活跃 Workspace 表:
| Workspace | 描述 | 状态 |
|-----------|------|------|
| workspace/{YYYYMMDD}__{feature-name} | {总任务拆分方案} | ✅ 完成 |
| workspace/{YYYYMMDD}__{sub-1} | {子任务描述} | 🚧 待启动 |
| workspace/{YYYYMMDD}__{sub-2} | {子任务描述} | 🚧 待启动 |
拆分完成后,用户可对每个子任务分别调用 an-task 进入标准工作流。拆分方案中的子任务定义可作为 an-task 的 raw-input 使用。
| 情况 | 处理 |
|---|---|
| 用户想修改拆分方案 | 调整 split-plan.md 后重新确认 |
| 用户只想推进部分子任务 | 仅创建选定子任务的工作区 |
| 原始任务本身不大(预估 requirements < 200 行) | 告知用户无需拆分,建议直接使用 an-task |