---
name: an-task-split
description: 将过大的 AI Native 任务拆成目标清晰、可独立 Review 的子任务，并创建带稳定父子 ID 的任务 Artifact。用户要求拆分、分解或规划大任务时使用。
---

# AI Native 任务拆分

拆分本身是一个 L2 或 L3 任务，阶段和状态遵循 `conventions/workflow.md`。目标是形成可独立执行、检查和归档的子任务，而不是按固定行业模块切割。原任务足够小时停止拆分，改用 `$an-task`。

## 一、父 Artifact

先定位父 Artifact。用户尚未创建父任务时，按 `$an-task` 的规则创建一个 L2 拆分 Artifact，再继续执行；不得假定父目录已经存在。

父 Artifact 的 `raw/task.md` 保存原始大任务，`requirements/requirements.md` 保存整体目标、范围、约束和完成标准。

## 二、拆分设计

从目标边界、产出边界、依赖关系、风险和可独立检查性选择拆分方式。每个子任务必须：

- 有单一清晰目标和独立完成标准。
- 有明确产出边界，不与兄弟任务共同写同一事实源。
- 能独立 Review；不能独立判断时继续拆分或合并。
- 明确依赖 ID 和执行顺序。
- 保留完成任务所需的必要上下文，不使用任意行数作为门禁。

将最终方案写入父任务的 `spec/split-plan.md`：

```markdown
# 拆分规范

## 子任务
| ID | 目标 | 核心完成标准 | 依赖 ID | Artifact |
|----|------|--------------|---------|----------|
| ... | ... | ... | ... | ... |
```

## 三、创建子任务

1. 为每个子任务创建独立目录和 `artifact.json`。
2. 子任务 `artifact.json.parentArtifactId` 写父 Artifact 的稳定 ID，不写会随移动失效的相对目录。
3. `raw/task.md` 记录父 ID、拆分规范引用和子任务原始范围。
4. `requirements/requirements.md` 写入唯一稳定 ID 的完成标准和依赖 ID。
5. 初始状态使用 `pending`，并登记到 `artifacts/index.json`。
6. 将实际创建结果记录到父任务的 `execution/summary.md`，并把每个子 Artifact 以 `{ kind: "artifact-reference", path, description }` 加入父任务 `deliverables`。

引用父任务时按稳定 ID 搜索活跃索引和 `_archived/`，因此父任务移动后引用仍然有效。

## 四、Review 与归档

父任务的 `review/review.json` 必须逐项检查：

- 每个 spec 子任务都已创建并进入活跃索引。
- 每个子任务都有 `artifact.json`、raw、requirements、父 ID 和依赖信息。
- 子任务共同覆盖父任务范围且没有冲突写入。
- 子任务均可独立判断完成状态。

父任务 PASS 后标记 `completed` 并调用 `$an-archive`；子任务继续保留在活跃索引中。REVIEW 只有记录用户明确接受后才能归档，BLOCKED 继续处理。
