split-task

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Divide and Conquer

分而治之

Evaluate a task's complexity and, if warranted, split it into smaller, focused sub-tasks.

评估任务的复杂度，必要时将其拆分为更小、更聚焦的子任务。

Instructions

使用说明

The user's query is in

$ARGUMENTS

(a task ID like

, optionally followed by

--force

to skip the complexity check).

Look up the task: Run
```
taskmd get $ARGUMENTS
```
to find the task
- If not found, run
```
taskmd list
```
  to show available tasks and ask the user which one they meant
Read the task file with the
```
Read
```
tool to get the full description, subtasks, and acceptance criteria
Assess complexity to decide whether the task should be divided. Consider:
- Effort field:
```
large
```
  effort tasks are good candidates;
```
small
```
  tasks almost never need splitting
- Subtask count: Tasks with 5+ checkbox items that span distinct concerns are candidates
- Scope breadth: Tasks that touch multiple unrelated areas (e.g., backend + frontend + docs) are candidates
- Independence: Subtasks that can be worked on in parallel by different people are candidates
- A task is NOT a good candidate if:
  - It has
```
small
```
    or
```
medium
```
    effort with fewer than 5 subtasks
  - Its subtasks are tightly coupled sequential steps of a single feature
  - Splitting would create trivial tasks that aren't worth tracking individually
If the task is NOT complex enough:
- Explain why the task doesn't warrant splitting (be specific about which criteria it fails)
- Do NOT create any files
- Only proceed if
```
$ARGUMENTS
```
  contains
```
--force
```
  or the user explicitly insists
If the task IS complex enough (or
```
--force
```
is used): a. Read the specification: Look for
```
docs/taskmd_specification.md
```
or
```
docs/TASKMD_SPEC.md
```
for the correct format b. Determine available IDs by scanning
```
tasks/**/*.md
```
with
```
Glob
```
:
- Extract numeric IDs from filenames (pattern:
```
NNN-description.md
```
  )
- Allocate the next N sequential IDs for the sub-tasks c. Design the split: Group the original task's work into 2-5 focused sub-tasks where each:
- Has a single clear responsibility
- Can be independently verified
- Includes relevant subtasks and acceptance criteria from the original d. Create sub-task files as siblings of the original task file (same directory), each with:
yaml
```
---
id: "<NNN>"
title: "<focused title>"
status: pending
priority: <inherit from parent>
effort: <estimated for this slice>
tags: <inherit relevant tags from parent>
parent: "<original task ID>"
created: <today's date YYYY-MM-DD>
---
```
Followed by a markdown body with:
- An H1 heading matching the title
- An
```
## Objective
```
  section describing this slice's goal
- A
```
## Tasks
```
  section with checkbox items (pulled or refined from the original)
- An
```
## Acceptance Criteria
```
  section
e. Update the original task (only the markdown body, not the frontmatter status):
- Add a
```
## Sub-tasks
```
  section listing the created sub-task IDs and titles
- Keep the original content intact for reference
Report the result:
- List each created sub-task file with its ID and title
- Summarize how the work was divided

用户的查询位于

$ARGUMENTS

中（格式为类似

的任务ID，可选后跟

--force

参数以跳过复杂度检查）。

查询任务：运行
```
taskmd get $ARGUMENTS
```
查找对应任务
- 如果未找到，运行
```
taskmd list
```
  展示所有可用任务，询问用户想要操作的是哪一个
使用
```
Read
```
工具读取任务文件，获取完整描述、子任务和验收标准
评估复杂度以判断是否需要拆分任务，考虑以下维度：
- 工作量字段：标记为
```
large
```
  工作量的任务适合拆分；
```
small
```
  工作量的任务几乎不需要拆分
- 子任务数量：包含5个及以上复选框项、且涉及不同领域的任务适合拆分
- 范围广度：涉及多个不相关领域（例如：后端 + 前端 + 文档）的任务适合拆分
- 独立性：可由不同人员并行开发的子任务所属的主任务适合拆分
- 任务不适合拆分的情况：
  - 工作量为
```
small
```
    或
```
medium
```
    且子任务少于5个
  - 子任务是单个功能下紧密耦合的顺序步骤
  - 拆分后会产生不值得单独追踪的琐碎任务
如果任务复杂度不足：
- 解释任务不适合拆分的原因（明确说明不符合哪项拆分标准）
- 不要创建任何文件
- 仅当
```
$ARGUMENTS
```
  包含
```
--force
```
  或用户明确要求时才继续拆分
如果任务复杂度足够（或使用了
```
--force
```
参数）： a. 读取规范：查找
```
docs/taskmd_specification.md
```
或
```
docs/TASKMD_SPEC.md
```
获取正确格式 b. 通过
```
Glob
```
扫描
```
tasks/**/*.md
```
确定可用ID：
- 从文件名中提取数字ID（格式：
```
NNN-description.md
```
  ）
- 分配接下来的N个连续ID给子任务 c. 设计拆分方案：将原任务的工作内容划分为2-5个聚焦的子任务，每个子任务满足：
- 具备单一清晰的职责
- 可独立验收
- 包含原任务中相关的子任务和验收标准 d. 在原任务文件的同级目录下创建子任务文件，每个文件包含：
yaml
```
---
id: "<NNN>"
title: "<focused title>"
status: pending
priority: <inherit from parent>
effort: <estimated for this slice>
tags: <inherit relevant tags from parent>
parent: "<original task ID>"
created: <today's date YYYY-MM-DD>
---
```
后跟markdown正文，包含：
- 与标题匹配的H1标题
- 描述本次拆分模块目标的
```
## 目标
```
  部分
- 带有复选框项的
```
## 任务
```
  部分（从原任务提取或优化）
- 一个
```
## 验收标准
```
  部分
e. 更新原任务（仅修改markdown正文，不修改前置元数据的状态）：
- 添加
```
## 子任务
```
  部分，列出创建的子任务ID和标题
- 保留原内容完整以便参考
汇报结果：
- 列出每个创建的子任务文件的ID和标题
- 总结工作拆分的方式