Back to Details

task-decomposer

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Task Decomposer Protocol

任务拆解协议

Break a complex task into independently executable, verifiable subtasks. Produce a structured plan first, get approval, then execute step by step with progress tracking.
将复杂任务拆解为可独立执行、可验证的子任务。先生成结构化规划，获得批准后，再逐步执行并跟踪进度。

Workflow

工作流

1. Analyze the task
2. Decompose into subtasks (with dependency map)
3. Present the plan and get approval
4. Execute sequentially — complete each step before moving to next
5. Produce summary report
1. 分析任务
2. 拆解为子任务（附带依赖关系图）
3. 提交规划并获得批准
4. 按顺序执行——完成每个步骤后再进行下一步
5. 生成总结报告

Step 1: Analyze the Task

步骤1：分析任务

Before decomposing, answer these questions:
  • What is the goal? What does success look like?
  • What is the scope? What is included, what is excluded?
  • Are there constraints? Technology, time, dependencies?
  • Is anything unclear? If so, ask one clarifying question — never multiple.
Do not generate subtasks until the task is clearly understood.
在拆解之前，先回答以下问题：
  • 目标是什么？ 成功的标准是什么？
  • 范围是什么？ 包含哪些内容，排除哪些内容？
  • 有哪些约束条件？ 技术、时间、依赖项限制？
  • 有哪些不明确的地方？ 如果有，只提出一个澄清问题——不要多个。
在任务明确之前，不要生成子任务。

Step 2: Decompose into Subtasks

步骤2：拆解为子任务

Each subtask must meet these criteria:
  • Atomic: Does one thing, contains no internal decision branches
  • Verifiable: You can definitively say "done" when completed
  • Independent (when possible): Can run without waiting for other subtasks
  • Has a concrete output: A file, a function, a document, a decision
每个子任务必须满足以下标准：
  • 原子性：只做一件事，内部没有决策分支
  • 可验证性：完成后可以明确判定“已完成”
  • 独立性（尽可能）：无需等待其他子任务即可执行
  • 有具体输出：一个文件、一个函数、一份文档、一项决策

Dependency Map

依赖关系图

Define relationships between subtasks:
  • Sequential (->): B cannot start until A completes
  • Parallel (||): Can run simultaneously — no shared dependencies
  • Optional (?): Not core, nice to have
How to handle parallel steps: Group 
||
steps together. Complete all steps in the group, then move to the next sequential step.
Group A (parallel): #1 || #2 || #3  -> complete all, then continue
Group B (sequential): #4 -> #5 -> #6
定义子任务之间的关系：
  • 顺序执行 (->)：B必须在A完成后才能开始
  • 并行执行 (||)：可同时进行——无共享依赖项
  • 可选执行 (?)：非核心需求，属于锦上添花
并行步骤处理方式： 将
||
步骤归为一组。完成组内所有步骤后，再进入下一个顺序步骤。
Group A (parallel): #1 || #2 || #3  -> 全部完成后再继续
Group B (sequential): #4 -> #5 -> #6

Dependency Visualization

依赖关系可视化

Use mermaid for complex dependency graphs:
mermaid
graph LR
    T1["#1 Data Model"] --> T3["#3 CRUD Operations"]
    T2["#2 DB Connection"] --> T3
    T3 --> T4["#4 API Endpoints"]
    T4 --> T5["#5 Tests"]
对于复杂的依赖关系图，使用mermaid：
mermaid
graph LR
    T1["#1 Data Model"] --> T3["#3 CRUD Operations"]
    T2["#2 DB Connection"] --> T3
    T3 --> T4["#4 API Endpoints"]
    T4 --> T5["#5 Tests"]

Step 3: Present the Plan

步骤3：提交规划

Show the plan to the user using the format in 
templates/task-plan.md.tmpl
and ask for approval.
Do not start execution without explicit user approval.
使用
templates/task-plan.md.tmpl
中的格式向用户展示规划，并请求批准。
未获得用户明确批准前，不要开始执行。

Step 4: Execute Step by Step

步骤4：逐步执行

After approval, complete each subtask:
  1. Before starting, print a header: 
    ### [#N] Task Name
  2. Execute the task — write code, create files, research, document
  3. On completion, print: 
    Completed: [what was produced]
  4. Move to the next subtask
On failure:
  • Explain the error
  • Suggest an alternative path
  • Ask the user: "Continue or fix this first?"
Escalation rule: If 2 consecutive subtasks fail, stop automatically and ask:
"2 consecutive steps failed. Should we review the plan together before continuing?"
获得批准后，完成每个子任务：
  1. 开始前，打印标题：
    ### [#N] 任务名称
  2. 执行任务——编写代码、创建文件、调研、文档编写
  3. 完成后，打印：
    已完成：[产出内容]
  4. 进入下一个子任务
执行失败时：
  • 解释错误原因
  • 建议替代方案
  • 询问用户：“继续执行还是先修复该问题？”
升级规则： 如果连续2个子任务失败，自动停止并询问：
“连续2个步骤执行失败。我们是否应该先一起重新审核规划再继续？”

Cross-Skill Integration

跨技能集成

  • checkpoint-guardian: During execution, critical actions (file deletion, DB writes, deploys) should trigger risk assessment checkpoints.
  • multi-brain: For complex subtasks where the approach is unclear, use 3-perspective evaluation before committing to an implementation.
  • checkpoint-guardian：执行过程中，关键操作（文件删除、数据库写入、部署）应触发风险评估检查点。
  • multi-brain：对于方法不明确的复杂子任务，在确定实现方案前，先进行三方视角评估。

Step 5: Summary Report

步骤5：总结报告

When all subtasks are done, present a summary using 
templates/task-summary.md.tmpl
.
所有子任务完成后，使用
templates/task-summary.md.tmpl
生成总结报告。

When to Skip

跳过场景

Do not decompose — respond directly when:
  • Single-step, clear task ("translate this file", "fix this bug")
  • User already knows the steps and only wants execution
  • Task can be completed in under 3 minutes
See 
references/SKIP_CONDITIONS.md
for the full decision matrix.
当满足以下情况时，无需拆解任务，直接响应：
  • 单步骤、明确的任务（如“翻译这个文件”“修复这个bug”）
  • 用户已经知晓步骤，仅需要执行
  • 任务可在3分钟内完成
完整决策矩阵请参考
references/SKIP_CONDITIONS.md
。

References

参考资料

  • See 
    references/PLAN_TEMPLATE.md
    for the plan output structure.
  • See 
    references/EXAMPLES.md
    for worked examples including a real code output.
  • See 
    references/SKIP_CONDITIONS.md
    for when to skip decomposition.
  • 规划输出结构请参考
    references/PLAN_TEMPLATE.md
    。
  • 包含真实代码输出的示例请参考
    references/EXAMPLES.md
    。
  • 无需拆解的场景请参考
    references/SKIP_CONDITIONS.md
    。

Templates

模板

  • Use 
    templates/task-plan.md.tmpl
    for presenting the plan to the user.
  • Use 
    templates/task-summary.md.tmpl
    for the completion report.
  • 向用户展示规划时使用
    templates/task-plan.md.tmpl
    。
  • 完成报告使用
    templates/task-summary.md.tmpl
    。