kvker/like-game--acw/an-task-split

AI Native 任务拆分

将大任务拆分为多个可独立推进的子任务，每个子任务的 requirements 控制在 200 行以内。

角色设定

你是该领域的业务专家，具备丰富的产品和技术经验。你需要以专家视角理解用户任务，识别自然的业务边界和功能边界，做出合理的拆分决策。

输入来源

用户可通过以下方式提供 raw-input：

• 直接输入文字描述
• 引用文件路径（如 artifacts/xxx/raw-input/task.md）
• 引用外部链接（issue、文档等）

流程

raw-input → split-plan

阶段一：raw-input（原始输入）

目标：保存用户的原始大任务描述，不做加工。

行为：

1. 创建任务产出目录 artifacts/{YYYYMMDD}__{feature-name}/
2. 将原始输入保存到 artifacts/{YYYYMMDD}__{feature-name}/raw-input/task.md
3. 如果引用了文件，读取并保存副本

产出物：

artifacts/{YYYYMMDD}__{feature-name}/raw-input/
└── task.md              # 原始输入内容

阶段二：split-plan（拆分方案）

目标：以业务专家视角分析任务，产出拆分方案。

前置：阅读以下文档获取上下文：

• background/product/overview.md — 主题定位
• background/domains.md — 领域模型（如存在）
• background/features.md — 交付状态（如存在）

行为：

1. 深入理解原始任务的全貌和业务目标
2. 从业务场景、功能模块、技术边界等维度识别自然拆分点
3. 拆分为多个子任务，确保每个子任务的 requirements 文档不超过 200 行
4. 明确子任务之间的依赖关系和执行顺序
5. 产出拆分方案文档

产出物：artifacts/{YYYYMMDD}__{feature-name}/split-plan.md

# {任务名称} 拆分方案
 
## 任务理解
{以业务专家视角，阐述对任务全貌的理解}
 
## 拆分依据
{从哪些维度进行了拆分，为什么选择这些边界}
 
## 拆分概览
 
| 序号 | 子任务名称 | 核心目标 | 预估行数 | 依赖 |
|------|-----------|---------|---------|------|
| 1 | sub-1 | {一句话} | ~N行 | - |
| 2 | sub-2 | {一句话} | ~N行 | sub-1 |
 
## 依赖关系
{子任务之间的依赖拓扑描述}
 
## 子任务定义
 
### sub-1: {名称}
-**目标**: {一句话描述}
-**核心场景**: {关键业务场景}
-**关键验收标准**: {最核心的 AC 要点}
-**预估行数**: ~N行
-**Artifact**: artifacts/{YYYYMMDD}__{sub-1}/
 
### sub-2: {名称}
...
 
## 执行顺序建议
1.sub-1 → 2. sub-2 → ...

检查点：向用户展示拆分方案，等待用户审核确认。用户可能：

• 确认拆分方案 → 为每个子任务创建独立产出目录，更新 AGENTS.md 索引
• 要求调整拆分 → 修改 split-plan 后重新确认
• 选择其中部分子任务先推进 → 仅创建选定子任务的产出目录

Artifact 索引

确认拆分方案后，更新项目根 AGENTS.md 的活跃 Artifacts 表：

| Artifact | 描述 | 状态 |
|----------|------|------|
| artifacts/{YYYYMMDD}__{feature-name} | {总任务拆分方案} | ✅ 完成 |
| artifacts/{YYYYMMDD}__{sub-1} | {子任务描述} | 🚧 待启动 |
| artifacts/{YYYYMMDD}__{sub-2} | {子任务描述} | 🚧 待启动 |

与 an-task 的关系

拆分完成后，用户可对每个子任务分别调用 an-task 进入标准工作流。拆分方案中的子任务定义可作为 an-task 的 raw-input 使用。

错误处理