# Split Task

> 当用户已有确认过的技术设计（理想来自 make-design），要在编码前把它拆成可独立验收、带依赖与验证方式的开发任务清单时使用——如"拆任务、把技术方案拆成开发任务、生成 tasks、列实现任务清单、把设计落地成可执行任务"。不要用于：技术方案还没定（先 make-design）、行为还没钉死（先 write-spec）、想法还模糊（先 refine-idea）、写具体实现代码或逐行施工单、调试、代码评审。

- Skill: `rollrollroll/split-task` (Agent Skill, multi-file: 6 files)
- Install (CLI): `npx skillmds@latest add rollrollroll/split-task`
- Raw SKILL.md: https://api.skillmd.com/api/skills/rollrollroll/split-task/raw
- Safety review: PASS (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: RollRollRoll (https://skillmd.com/u/rollrollroll)
- Updated: 2026-08-19
- Page: https://skillmd.com/skills/rollrollroll/split-task

---


# Split Task — 任务拆分 Skill

## 你的任务

把一份**已确认的技术设计**（理想情况下来自 make-design），转化为一份**可被 review、
每个任务都能独立验收**的开发任务清单。你要把"用这套架构、这些决策来实现"翻译成
"按什么顺序、拆成哪些任务来落地"，钉死四件事：

1. **拆成独立可验收的垂直切片** —— 每个任务都写得出"完成判据 + 怎么验证"，而不是"写数据库层"这种半成品。
2. **定序与并行** —— 任务间依赖关系、哪些可并行、高风险/高不确定性的前置。
3. **易漏任务不漏** —— 用拆分探针逐项扫数据迁移 / 测试 / 配置 / 回滚 / 可观测等"不显眼但要命"的维度。
4. **每个设计点都有任务落地** —— design 每个组件/决策、spec 每条 MUST/MUST NOT 都对得上某个任务，不落空、不镀金。

**刻意止步于此**：不写逐行实现代码、不写含代码的施工单、不替任务做技术决策——逐行实现是下游 execute-task（执行）的事，技术决策是上游 make-design 的事。你的产出是一份"任务边界清楚、依赖理顺、每个都可验收、
对得上设计与 spec"的清单，而不是代码，也不是架构。

> 一句话：把技术设计的"用这套架构 / 这些决策来实现它"，翻译成"拆成这些**可独立验收**的任务、
> 按**这个依赖顺序**推进，且每条需求 / 每个组件都对得上某个任务"。

## 核心理念

任务清单是**编码前的最后一道闸门**（spec 是行为闸门、design 是技术闸门）。设计定了"怎么实现"，
但"拆成哪些任务、什么顺序、每个怎么算做完"里——每一个验收说不清的任务、每一类被漏掉的工作
（迁移、回滚、配置）、每一处没理顺的依赖，都会在编码期变成卡壳、返工或"做到一半发现少了前置"。
最便宜的消除时机，是在 code 存在之前——把任务摆开、切成可独立验收的片、理顺依赖、逐条对回设计。

split-task 不挖意图（那是 refine-idea），不定行为（那是 write-spec），不做技术决策（那是 make-design），
也不写代码（那是执行）。它只做一件事：**把已确认的技术设计，拆成边界清楚、可独立验收、覆盖完整的任务清单。**

## 何时用 / 何时不用

**适用**：

- 技术设计已确认（或手上有 make-design 的技术方案），准备进入编码前，需要把任务拆出来、理顺顺序。
- 要把一个功能 / 改动落地为"可被领取、可逐个验收、可勾选追踪"的开发任务。
- 协作中需要一份"执行期可对照、每个任务做没做完可逐条核对"的依据。

**不适用**（别硬套）：

- 技术方案还没定 / 没确认 → 先 make-design。任务必须站在确认过的技术设计上，否则是给没定的方案拆任务。
- 行为 / 需求还没钉死 → 先 write-spec；想法还模糊 → 先 refine-idea。
- 要的是逐行实现代码 / 含代码的施工单 → 那是下游 execute-task（执行）。
- 已在写代码、定位 bug、做评审。

**⚠️ 加载约束**：本 skill 的产出（任务清单）**最终必须经一个能 review 的活人确认才放行进入编码**。
与 make-design 一致——允许**从 design + spec + 代码库推断常规拆分**（显式标注假设），但有两条硬线：

- **会改变清单形状 / 需用户偏好**的点（切片边界、任务粒度、关键依赖顺序、哪些延后到后续版本）**停下来交用户拍板**。
- 禁止在 CI / 定时任务 / 自治循环里把它当"自动产任务、无人 review 就开干"的工具——那种场景遇到
  "没有任务清单"，正确做法是产出**带假设标注的草案并标记为待 review 的 blocker**，而不是自动定稿就开始编码。

## 招牌机制：垂直切片 + 拆分探针 ⭐

这是 split-task 区别于"随手列个 todo"的核心。一份任务清单不是把设计里的模块名抄成几行待办，
而是让每个任务都过两关、再受两道闸门收敛。与 make-design 的「决策探针 + 方案对比锁定」严格同构。

### 关一：每个任务独立可验收

每个任务必须写得出 **「完成判据（验收标准）+ 怎么验证（验证方式）」**。

- 写得出可验证的完成判据 → 它是一个任务。
- 写不出（只能说"把数据层写好""处理一下错误"）→ 它**要么太大该拆，要么太空该并**，别用"写好 X"
  把没想清楚盖过去。

> 检验：把这个任务交给另一个人，他做完后能照着"验收标准"自己判断"做完了没有"吗？不能，就还没拆清。

### 关二：拆分探针强制覆盖

光照着设计里的模块拆，会漏掉一半真正要做的工作——漏在数据迁移、测试、配置、回滚、可观测、
依赖安装这些"设计文档不显眼、但不做就上不了线"的维度上。拆分探针逐项扫一组易漏任务维度，
每个维度强制表态：**需任务 / 不适用 / 延后**。

- 维度示例：数据迁移 / 测试 / 配置与环境变量 / 文档 / 回滚 / 可观测（日志·指标）/ 集成点 /
  依赖安装 / 构建·CI / 接口契约落地 / 种子数据。
- 关键：每个维度都要有结论（拆了任务 / 明确不适用 / 显式延后），"忘了想"和"想过判定不适用"是两回事。

（维度全清单与每个维度具体问什么，见 [references/split-probes.md](references/split-probes.md)。）

### 闸门一：任务分级（防笨重 + 防过碎）

不是每个动作都单列一个任务，也不是一个任务塞下整个功能。两头收敛：

- **任务大小以 S / M 为宜**（约 1~5 个文件、一个工作单元内能完成）。
- **XL 必拆** —— 跨多个关注点、说不清单一验收的，继续拆到可独立验收。
- **过碎则合并** —— "改一行配置"这种别单列，并入相关任务。
- **垂直切片优先，但允许必要的地基任务** —— 优先让任务穿透各层、可独立验收（反对"先做全部 DB 再做全部 API"）；
  但建表 / 脚手架 / 公共依赖这类天然的地基，可作为前置任务单列。

### 闸门二：设计 & spec 覆盖核对（防落空与镀金）

design 每个组件 / Decision、spec 每条 Requirement / MUST NOT → 由哪个任务覆盖。这是 split-task 独有的闸门，
确保**不落空**（每个设计点都有任务落地）、**也不镀金**（不冒出 design / spec 之外的任务）。

（切片怎么切、分级判据、依赖与并行怎么排、覆盖核对怎么做，见 [references/slicing-method.md](references/slicing-method.md)。）

**漏斗顺序**：先用垂直切片**圈出有哪些任务**（覆盖面）→ 用拆分探针**补漏**（易漏维度）→
用分级**收敛**（大小 / 合并 / 前置，防笨重）→ 最后做**覆盖核对**（对齐 design + spec）。

## 工作流程（阶段 0 + 四个工作阶段）

### 阶段 0 · 定位与上下文

1. **接上游**：读 design（`docs/design/*` 或用户指明的位置）作为主输入，读 spec（`docs/specs/*`）取验收口径。
   **无 design → 视为前置缺失**：任务必须站在确认过的技术设计上；没有就**建议先 make-design**，
   不要自己去补技术决策（补决策是 make-design 的职责，越界了）。
2. **扫代码库（轻量）**：技术栈、现有结构、**测试怎么跑、构建怎么跑**——这决定任务的"涉及文件"
   与"验证方式"能落成什么形式。注意：这是为了让任务落地，不是重做架构调研（现状认知信任 design）。
3. **判 greenfield / brownfield**：
   - 全新系统 / 独立新模块 → 拆全量任务清单。
   - 改既有系统 → 用 **delta**：聚焦"改动相关的任务 + 迁移 / 兼容 / 回滚任务"，不重列与本次无关的既有工作。
4. **判规模**：若这其实是多个独立子系统，**先提示拆分**，逐个出任务清单，别把一份清单撑成全系统施工总表。

### 阶段 1 · 切片与定序

1. **垂直切片**：按"独立可验收的窄而完整的路径"切任务，而非按技术层横切。必要的地基任务（建表 / 脚手架）单列为前置。
2. **跑拆分探针补漏**：逐项扫易漏维度，判定 **需任务 / 不适用 / 延后**，把漏的任务逼出来。
3. **定序与并行**：建依赖关系（A 依赖 B）、标注**可并行**的任务（互不冲突文件）、把**高风险 / 高不确定性**的任务前置
   （先验证不确定的部分，避免后面返工）；每 2~3 个任务设一个 checkpoint（验证测试 / 构建 / 核心流程）。
4. **分级收敛**：任务大小 S/M，XL 拆、过碎并。
5. **推断优先，关键点停下确认**：能从 design + spec 推断的拆分直接推断（标注假设）；
   **切片边界 / 粒度 / 关键依赖顺序 / 哪些延后**这类会改变清单形状、或需用户偏好的，**停下来给推荐并问**。

> 检验：「这个切法 / 这个顺序定错了，好不好改？」——会让一批任务推倒重排、且难改 → **必须停下确认**，不许靠推断蒙混。

### 阶段 2 · 起草任务清单

按 [references/task-template.md](references/task-template.md) 写。每个任务含：

- **目标**：这个任务要交付什么（一句话，落到可验收的结果）。
- **切片**：它属于哪条垂直切片 / 是不是地基任务。
- **涉及文件**：创建 / 修改 / 测试哪些文件（先定文件结构，借 superpowers）。
- **依赖**：依赖哪些前置任务（无依赖则标 none）；可并行 / 高风险标注。
- **验收标准**：完成判据，可被另一个人独立判断（关一）。
- **验证方式**：怎么验证（最好对应"测试怎么跑 / 构建怎么跑"，如 `pytest tests/test_x.py`）。
- **覆盖**：这个任务落地了 design / spec 的哪些条目（关联闸门二）。
- **checkbox**：`- [ ]` 便于执行阶段勾选追踪。

清单整体还要含：**依赖与并行视图**（顺序 / 哪些可并行 / checkpoint 在哪）+ **覆盖核对表**（design&spec → 任务）。

> **下游可解析约束**：迁移、兼容、回滚只要判定为“需任务”，就必须写成完整的
> `### Task N: ...`，包含与其他任务相同的字段和 checkbox。可以另设索引汇总这些任务，
> 但不能只在“迁移 / 回滚”章节留一条游离 bullet；否则 execute-task 无法机械抽取和追踪。

### 阶段 3 · 自检（双重，落盘前过一遍）

**① 任务卫生**（借 superpowers）：

- 占位符 / TODO / "待补充"的任务？补全或删除。
- 自相矛盾？（两个任务职责重叠、依赖关系打架）
- 范围过大？需要拆成多份清单？
- 歧义？（某个任务的验收能有两种解读 → 写死一种）

**② 覆盖自检**（招牌机制回扫）：

- 每个拆分探针维度都表态了吗（需任务 / 不适用 / 延后）？
- 每个任务都有可独立判断的**验收标准 + 验证方式**吗（关一）？
- design 每个组件 / Decision、spec 每条 Requirement / MUST NOT 都有任务落点吗（不落空）？有没有 design/spec 之外的镀金任务？
- 依赖关系**无环**、顺序可执行吗？高风险任务前置了吗？
- 任务大小合适吗（没有 XL 没拆、没有过碎该并）？
- 推断出来的拆分，假设都显式标注了吗？

就地修复，不必重复 review。

### 阶段 4 · 用户 review 门禁（硬门）

1. **落盘**：把任务清单写入仓库。位置见下文「产物与落盘」。
2. **请用户 review**，并明确这条规矩：
   > **未通过 review 的任务清单，不进入编码。**
3. 用户要改 → 回阶段 1 / 2 / 3 修订并重过自检；用户**显式确认** → 过门。
4. **过门后**：可以一句话提示"需要的话，可据此进入 execute-task（逐个任务执行）"，
   但**不自动开始编码、不自动跑任务**。本 skill 到"任务清单确认"为止。

**哪些回答不算 "yes"**（同 refine-idea / write-spec / make-design 的门禁纪律）：

- "你看着办 / 都行" = 委托，不是决策。
- "听起来不错" = 模糊回应。
- 沉默后一句"那就开始吧" = 放弃，不是确认。

## 产物与落盘

- **默认单份任务清单文档**，内容是任务（目标 / 切片 / 文件 / 依赖 / 验收 / 验证 / 覆盖 + checkbox）+
  依赖与并行视图 + 覆盖核对表。
- **位置**：跟随仓库既有约定——若已有 OpenSpec 式 `openspec/changes/<change>/tasks.md` 或 `docs/tasks/` 布局，就跟随；
  否则默认 `docs/tasks/<YYYY-MM-DD>-<主题>-tasks.md`（目录不存在先跟用户确认）。
- **brownfield** 用 delta，聚焦改动相关任务 + 迁移 / 兼容 / 回滚，不重列全量；其中判定为“需任务”的
  迁移 / 兼容 / 回滚必须使用完整 `Task N` 结构。
- 规模极大 / 多子系统时，**可提议**拆成多份，但这是 scale-up，不是默认——别给小改动套重型结构。

## 核心原则（不要违反）

1. **每个任务可独立验收，不是半成品** —— 都要写得出"完成判据 + 怎么验证"，否则该拆或该并。
2. **先站在 design 与 spec 上，再拆任务** —— 脱离技术设计（怎么实现）或 spec（验收口径）的任务清单是空拆。
3. **拆分探针是强制项** —— 数据迁移 / 测试 / 配置 / 回滚 / 可观测是漏任务的重灾区，逐项扫，别省。
4. **垂直切片优先，分级收敛** —— 任务穿透各层可独立验收；S/M 为宜，XL 拆、过碎并，别横切成"半层任务"。
5. **每个设计点都要对得上号** —— design 组件 / Decision、spec 的 MUST / MUST NOT 都有任务落点，且不拆 spec 之外的任务。
6. **依赖理顺、高风险前置** —— 依赖无环、顺序可执行；不确定性最高的先验证。
7. **推断可以，关键必停、最终必 review** —— 常规拆分可推断 + 标注假设；切片边界 / 粒度 / 顺序停下问；定稿经活人确认才进编码。
8. **止步于任务清单，不下沉代码** —— 逐行实现 / 含代码施工单留给下游 execute-task，不自动往下、不写代码。

## 终止条件（可检验）

- **达标即停**：当每个任务都有验收 + 验证、每个拆分探针维度都表态、design 每个组件 / spec 每条都有任务落点、
  依赖无环可执行——任务清单就够了，进入 review 门禁，别为"更细的任务"无限拆下去。
- **兜底①**：拆到一半发现 design 本身有没定的技术决策（你要拆的任务依赖一段缺失的设计）→ **停下退回 make-design**，
  别用任务清单去替设计补决策。
- **兜底②**：某个切片边界 / 依赖顺序反复定不下来、且缺用户私有信息（偏好、优先级、外部约束）→ **停下把判断告诉用户**、
  交他拍板，别在原地空转或硬猜。

## 自检清单（落盘前过一遍）

- [ ] 每个任务都有可独立判断的**验收标准 + 验证方式**（关一）？
- [ ] 每个**拆分探针维度**都表态了（需任务 / 不适用 / 延后）？
- [ ] design 每个组件 / Decision、spec 每条 **Requirement / MUST NOT** 都有任务落点（覆盖核对），没落空？
- [ ] 通篇**没有 design / spec 之外的镀金任务**？
- [ ] 任务**大小合适**（没有 XL 没拆、没有过碎该并）、**垂直切片优先**？
- [ ] 依赖关系**无环**、顺序可执行，**高风险前置**、设了 checkpoint？
- [ ] 推断出来的拆分，**假设都显式标注**了？
- [ ] brownfield 用了 **delta**（只列改动相关 + 迁移/回滚），没重列全量？
- [ ] 所有“需任务”的迁移 / 兼容 / 回滚都写成了完整 `Task N`，没有游离 bullet？
- [ ] 会改变清单形状的点（切片边界 / 粒度 / 顺序 / 延后）都**停下问过**用户，不是自己拍板的？
- [ ] 动笔前**读过 design 与 spec、轻量扫过代码库**（结构 / 测试怎么跑 / 构建怎么跑）？
- [ ] 拿到的是**显式 review 确认**，不是"你看着办 / 听起来不错"？
- [ ] 全程**止步于任务清单**，没下沉到逐行实现、没写代码？

## 一次完整示范（照着这个节奏走）

> 接 make-design 那份"实验清单"技术设计，看它怎么被拆成可执行任务清单。三件套用同一案例贯穿。

**输入（来自 make-design 技术设计，节选）**

> brownfield：既有 Flask + SQLite + pytest 应用里新增"实验清单"只读功能。
> 架构：`models.py` 的 `list_experiments()` 纯函数（取数 + 状态校验 + 稳定排序）；`routes.py` 的
> `GET /experiments` 调它渲染 `experiments.html`；无写路由。数据模型：`experiments(id, name,
> status CHECK in draft/running/done, owner NULL, created_at)`。测试策略：pytest 测 `list_experiments()`
> （正常 / 空 / 非法状态 / owner 空 / 稳定排序）+ 一条路由 smoke test。

**阶段 0 · 定位与上下文**

> design 齐全，直接接住。扫项目：Flask + SQLite，测试 `pytest`，无构建步骤。这是**在既有应用里加新功能** →
> brownfield delta：只列实验清单相关任务，不动既有部分。现状认知信任 design（make-design 已调研过）。

**阶段 1 · 切片 + 探针 + 定序**

> 按垂直切片切（数据 → 展示），地基任务前置；跑拆分探针补漏；多数维度不适用（只读小功能），正好演示**克制**：
>
> | 拆分探针维度 | 判定 | 处理 |
> |---|---|---|
> | 数据迁移 | 需任务 | T1 建 experiments 表 + CHECK 约束 |
> | 测试 | 需任务（嵌入式） | 验收用 pytest，融入 T2 / T3 的验证方式，不另列纯测试任务 |
> | 接口契约落地 | 需任务 | T3 `GET /experiments` |
> | 种子数据 | 需任务（小） | 并入 T1（插几条演示数据） |
> | 配置 / 依赖安装 / 构建 CI | 不适用 | 无新配置 / 无新依赖 / 沿用现有 pytest |
> | 回滚 / 可观测 | 不适用 | 新增只读功能、无破坏性迁移、只读静态无需埋点 |
> | 文档 | 延后 | 内部小工具，本版不写文档（进延后） |
>
> 切出 4 个任务，依赖链 T1 → T2 → T3 → T4，规模小基本线性、无特别高风险：
>
> - **T1（地基/schema）** 建 `experiments` 表 + CHECK 约束 + 几条种子数据
> - **T2（数据层切片）** `list_experiments()` 纯函数：取数 + 状态校验 + 稳定排序
> - **T3（展示层切片）** `GET /experiments` 路由 + `experiments.html`：倒序展示、空态、owner 空兜底
> - **T4（MUST NOT 收口）** 核对无写路由 / 无表单 / 无图表 / 无外部同步入口
>
> 切片边界（数据层 / 展示层分开）会影响清单形状，停下确认：
>
> > 「我打算按'数据层（T2）/ 展示层（T3）'切两片，建表（T1）作前置地基，最后用 T4 收口三条 MUST NOT。
> > 你认可这个切法和 T1→T2→T3→T4 的顺序吗？」

**用户**：认可。

**阶段 2 · 起草（节选）**

> ## Task 2: 实验查询与校验 `list_experiments()`
> - 切片：数据查询层（DB → 纯函数，可独立测）
> - 涉及文件：`models.py`(改)、`tests/test_models.py`(新)
> - 依赖：T1（建 experiments 表）；可并行：否；高风险：否
> - 验收标准：非法 status 标记数据异常（不静默显示）；空集合返回 `[]` 不报错；
>   created_at 相同按 id 稳定排序；owner 为空不抛错
> - 验证方式：`pytest tests/test_models.py`（覆盖正常 / 空 / 非法状态 / owner 空 / 稳定排序）
> - 覆盖：design `list_experiments()`；spec Req「状态约束」「稳定排序」
> - [ ] 完成
>
> 〔T1 / T3 / T4 同构略〕
>
> ## 依赖与并行视图
> - 顺序：T1 → T2 → T3 → T4（线性）
> - 可并行：无（小项目，强依赖链）
> - checkpoint：T2 后跑一次 `pytest`（数据层绿）；T3 后开页面 + 路由 smoke
>
> ## 覆盖核对表
> | design / spec 条目 | 任务落点 |
> |---|---|
> | design `experiments` 表 / 数据模型 | T1 |
> | design `list_experiments()` | T2 |
> | design `GET /experiments` + 模板 | T3 |
> | spec Req 只读展示（含空态 / owner 空 / 倒序） | T3 |
> | spec Req 状态约束 | T1（CHECK）+ T2（查询层校验） |
> | spec Req 稳定排序 | T2 |
> | spec MUST NOT 编辑 / 同步 / 图表 | T4 |
> | design 测试策略 | T2 + T3 的验证方式 |

**阶段 3 · 自检**

> 每个任务都有验收 + 验证 ✓；拆分探针每维表态（含"不适用 / 延后"）✓；
> design 组件与 spec 每条 MUST / MUST NOT 在覆盖核对表都有落点、无镀金 ✓；
> 依赖 T1→T2→T3→T4 无环可执行 ✓；任务大小 S/M ✓；文档"延后"已标注 ✓。

**阶段 4 · review 门禁**

> 任务清单已写入 `docs/tasks/2026-06-22-experiment-list-tasks.md`。请 review；未过 review 不进入编码。
>
> 〔用户显式确认后过门，提示"可据此进入 execute-task 执行"，不自动往下。〕

## 反例（不要这样做）

❌ 把 design 里的模块名抄成几行 todo 当任务 —— 没有验收标准、没法判断做没做完。
❌ 按技术层横切（"任务1：全部数据库""任务2：全部 API""任务3：全部 UI"）—— 每个都不可独立验收，违背垂直切片。
❌ 一个任务塞下整个功能（XL 不拆），或给"改一行配置"单列一个任务（过碎不并）。
❌ 只照设计里写到的模块拆，漏掉数据迁移 / 测试 / 配置 / 回滚 / 可观测 —— 拆分探针没逐项扫。
❌ 任务清单不对照 design / spec，漏了某个组件或某条 MUST 没人做，或冒出一堆 spec 之外的"顺手加的"任务（镀金）。
❌ 依赖有环 / 顺序排错（后置任务被前置任务依赖），或把高不确定性的任务放到最后才做。
❌ design 还没确认就开始拆任务 —— 给没定的方案拆活，该先 make-design。
❌ 把逐行实现代码、含代码的施工单写进任务里 —— 越界到下游 execute-task（那是执行 / 编码的事）。
❌ 自己替任务做技术决策（"这里改用 Redis"）—— 越界回 make-design。
❌ 切片边界 / 粒度 / 关键顺序自己拍板、不问也不留 review。
❌ brownfield 把与本次无关的既有工作也列进来 —— 该用 delta。
❌ 接 issue tracker / 外部平台发任务 —— 本链是本地文档驱动，不做外部集成。
❌ 没落盘、没让用户 review 就说"任务拆好了，开始写代码"。
❌ 在 CI / 自治循环里自动产任务清单、无人 review 就开干。

## 相关参考

- [references/task-template.md](references/task-template.md) —— 任务清单落盘模板
  （任务条目 + 依赖与并行视图 + 覆盖核对表；含 brownfield delta）。
- [references/split-probes.md](references/split-probes.md) —— 拆分探针清单：
  逐项易漏任务维度 + 每个维度具体问什么、怎么判"需任务 / 不适用 / 延后"。
- [references/slicing-method.md](references/slicing-method.md) —— 切片与定序方法：
  垂直切片怎么切、任务大小分级、依赖与 wave 并行怎么排、高风险前置 / checkpoint、覆盖核对怎么做。