Back to Details

task-breakdown

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Task Breakdown — Orchestrator

任务分解编排器

Productivity — Multi-agent orchestration. Break architecture into executable tasks and build them one at a time with AI agents.
Core Question: "Can an engineer pick up any single task and ship it independently?"
生产力工具 — 多Agent编排。将架构分解为可执行任务，借助AI Agent逐一构建。
核心问题： "工程师能否接手任意单个任务并独立完成交付？"

Inputs Required

所需输入

  • Architecture document, feature spec, or problem description to decompose
  • Target scope (MVP, full feature, spike)
  • 待分解的架构文档、功能规格说明或问题描述
  • 目标范围（MVP、完整功能、探索性开发）

Output

输出

  • .agents/tasks.md
  • .agents/tasks.md

Chain Position

流程位置

Previous: 
system-architecture
, 
discover
, or conversation context | Next: task execution (Phase 2)
Re-run triggers: When architecture changes after initial breakdown, when scope mode changes (e.g., full → minimal), or when tasks consistently fail acceptance criteria (indicates decomposition issues).
上一步：
system-architecture
、
discover
或对话上下文 | 下一步：任务执行（第二阶段）
重新触发条件： 初始分解后架构发生变更、范围模式变更（如完整→最小化），或任务持续未通过验收标准（表明分解存在问题）。

Context Resolution

上下文解析

Task-breakdown works from whatever context is available. It does NOT require artifacts on disk — conversation context from the current session is equally valid.
Resolution order:
  1. Conversation context — if discover or system-architecture ran in this session, their decisions are in context
  2. Artifacts on disk — 
    .agents/system-architecture.md
    , 
    .agents/spec.md
    , 
    .agents/design/user-flow.md
  3. Defer to discover — if neither exists, recommend running 
    /discover
    first. Do not conduct your own interview — clarification is discover's job.
If artifacts exist but their 
date
fields are older than 30 days, recommend re-running the source skill. Tip: 
/navigate status
gives a single-pass freshness report across all upstream artifacts.
任务分解工具可基于现有任意上下文工作。不要求磁盘上存在工件——当前会话的对话上下文同样有效。
解析优先级：
  1. 对话上下文 —— 若当前会话中已运行discover或system-architecture，其决策内容会被纳入上下文
  2. 磁盘上的工件 —— 
    .agents/system-architecture.md
    、
    .agents/spec.md
    、
    .agents/design/user-flow.md
  3. 调用discover工具 —— 若上述两者均不存在，建议先运行
    /discover
    。请勿自行开展需求访谈——需求澄清是discover的职责。
若工件存在但其
date
字段已超过30天，建议重新运行生成该工件的skill。提示：
/navigate status
可一次性生成所有上游工件的新鲜度报告。

Multi-Agent Architecture

多Agent架构

Agent Roster

Agent清单

AgentFileFocus
decomposer-agent
agents/decomposer-agent.md
Splits features into atomic, right-sized tasks
dependency-mapper-agent
agents/dependency-mapper-agent.md
Maps dependency graph, finds hidden dependencies
ordering-agent
agents/ordering-agent.md
Merges tasks + deps into risk-first ordered list
acceptance-agent
agents/acceptance-agent.md
Writes precise, verifiable acceptance criteria
critic-agent
agents/critic-agent.md
Quality gate review, sizing check, coverage trace
Agent文件核心职责
decomposer-agent
agents/decomposer-agent.md
将功能拆分为原子化、大小合适的任务
dependency-mapper-agent
agents/dependency-mapper-agent.md
绘制依赖关系图，发现隐藏依赖
ordering-agent
agents/ordering-agent.md
合并任务与依赖关系，生成风险优先的任务列表
acceptance-agent
agents/acceptance-agent.md
编写精确、可验证的验收标准
critic-agent
agents/critic-agent.md
质量把关评审、任务规模检查、覆盖追踪

Execution Layers

执行层级

Layer 1 (parallel):
  decomposer-agent ────────┐
  dependency-mapper-agent ──┘── run simultaneously

Layer 2 (sequential):
  ordering-agent ──────────── merges task list + dependency graph
    → acceptance-agent ────── writes criteria for ordered tasks
      → critic-agent ─────── final quality review
Layer 1 (parallel):
  decomposer-agent ────────┐
  dependency-mapper-agent ──┘── run simultaneously

Layer 2 (sequential):
  ordering-agent ──────────── merges task list + dependency graph
    → acceptance-agent ────── writes criteria for ordered tasks
      → critic-agent ─────── final quality review

Dispatch Protocol

调度协议

  1. Confirm scope mode — ask the user: "Are we decomposing everything (FULL), building exactly what's spec'd (LOCKED), or cutting to minimum (MINIMAL)?" Default to LOCKED if finished spec provided, MINIMAL if MVP mentioned.
  2. Extract durable decisions — before decomposing, identify and list the architectural decisions that every task will reference: route structures, database schema shape, key data models, auth approach, third-party service boundaries, deployment target. Write these as a "Shared Context" header in the task artifact so every task can reference them without repeating or diverging. If system-architecture.md exists, extract from there. If not, extract from conversation context.
  3. Layer 1 dispatch — send brief + scope mode + shared context to 
    decomposer-agent
    and 
    dependency-mapper-agent
    in parallel.
  4. Layer 2 sequential chain — pass both outputs to 
    ordering-agent
    , then ordered list to 
    acceptance-agent
    , then complete breakdown to 
    critic-agent
    .
  5. Revision loop — if critic returns FAIL, re-dispatch affected agents with feedback. Maximum 2 rounds.
  6. Assembly — merge into the task artifact format. Save to 
    .agents/tasks.md
    .
  1. 确认范围模式 —— 询问用户："我们是分解全部内容（FULL）、严格按照规格构建（LOCKED），还是精简至最小范围（MINIMAL）？" 若提供了完整规格，默认使用LOCKED模式；若提及MVP，则默认使用MINIMAL模式。
  2. 提取可复用决策 —— 分解前，识别并列出所有任务将参考的架构决策：路由结构、数据库 schema 形态、核心数据模型、认证方案、第三方服务边界、部署目标。在任务工件中写入「共享上下文」标题，让所有任务可直接引用，无需重复或偏离。若存在system-architecture.md，则从中提取；否则从对话上下文提取。
  3. 第一层调度 —— 将简介、范围模式及共享上下文并行发送给
    decomposer-agent
    和
    dependency-mapper-agent
    。
  4. 第二层串行流程 —— 将两者的输出传递给
    ordering-agent
    ，再将排序后的列表传递给
    acceptance-agent
    ，最后将完整的分解结果传递给
    critic-agent
    。
  5. 修订循环 —— 若critic返回FAIL，将反馈信息重新发送给受影响的Agent。最多循环2次。
  6. 组装 —— 合并为任务工件格式，保存至
    .agents/tasks.md
    。

Routing Rules

路由规则

ConditionRoute
Scope mode MINIMALdecomposer-agent actively cuts features before decomposing
Scope mode FULLdecomposer-agent captures everything; defer cuts to after
Scope mode LOCKEDdecomposer-agent follows spec exactly; flags gaps but doesn't add
Critic PASSAssemble and deliver
Critic FAILRe-dispatch cited agents with feedback
Revision round > 2Deliver with critic's remaining issues noted
条件路由处理
范围模式为MINIMALdecomposer-agent在分解前主动裁剪功能
范围模式为FULLdecomposer-agent捕获全部内容，裁剪操作延迟至分解后进行
范围模式为LOCKEDdecomposer-agent严格遵循规格执行，标记缺口但不新增内容
Critic返回PASS组装并交付工件
Critic返回FAIL将反馈信息重新发送给指定Agent
修订循环超过2次交付工件并标注critic指出的剩余问题

Critical Gates

关键质量 gate

Before delivering, the critic-agent verifies ALL of these pass:
  • Every task has exactly ONE acceptance test
  • No task depends on something not yet defined
  • Risky/uncertain work is front-loaded
  • All external config is in Prerequisites, not buried in tasks
  • A junior dev could verify each acceptance criterion
  • No task requires unstated knowledge to complete
  • Tasks are vertical slices (each delivers a testable increment through all layers). Horizontal-only tasks require explicit justification.
If any gate fails: the critic identifies which agent must fix it and the orchestrator re-dispatches with specific feedback.
交付前，critic-agent需验证以下所有项均通过：
  • 每个任务恰好对应一项验收测试
  • 无任务依赖未定义的内容
  • 高风险/不确定的工作被前置
  • 所有外部配置均在「前置条件」中声明，而非隐藏在任务内
  • 初级开发人员可验证每项验收标准
  • 无任务需要未明确说明的知识才能完成
  • 任务为垂直切片（每个任务交付可跨所有层级的可测试增量）。纯水平任务需提供明确理由。
若任意gate未通过： critic指出需修复的Agent，编排器将包含具体反馈的任务重新调度给该Agent。

Single-Agent Fallback

单Agent fallback方案

When context window is constrained or the decomposition is simple (fewer than 10 tasks expected):
  1. Skip multi-agent dispatch
  2. Confirm scope mode with the user
  3. Decompose using the Task Format and Sizing Rules below
  4. Map dependencies inline
  5. Order risk-first
  6. Write acceptance criteria for each task
  7. Run the Critical Gates checklist as self-review
  8. Save to 
    .agents/tasks.md
当上下文窗口受限或分解任务简单（预期任务数少于10个）时：
  1. 跳过多Agent调度
  2. 与用户确认范围模式
  3. 按照下方的任务格式和规模规则进行分解
  4. 内联绘制依赖关系
  5. 按风险优先排序
  6. 为每个任务编写验收标准
  7. 以关键质量gate清单作为自我评审
  8. 保存至
    .agents/tasks.md

Scope Modes

范围模式

ModeWhenBehavior
FULL SCOPEDiscovery, greenfield, "what would it take?"Capture everything — defer cuts to after decomposition
LOCKED SCOPESpec is final, ready to buildDecompose exactly what's written — flag gaps but don't add
MINIMAL SCOPEToo much on the plate, need an MVPActively cut before decomposing — ask "can we ship without this?" for each feature
Default to LOCKED SCOPE if the user provides a finished spec. Default to MINIMAL SCOPE if the user mentions MVP, prototype, or time pressure.
模式适用场景行为
FULL SCOPE（完整范围）需求探索、全新项目、「实现需要多少工作量？」场景捕获全部内容——裁剪操作延迟至分解后进行
LOCKED SCOPE（锁定范围）规格已最终确定，准备开始构建严格分解规格中明确的内容——标记缺口但不新增内容
MINIMAL SCOPE（最小范围）工作量过大，需交付MVP分解前主动裁剪功能——对每个功能提问「没有它能否交付？」
若用户提供完整规格，默认使用LOCKED SCOPE；若用户提及MVP、原型或时间压力，默认使用MINIMAL SCOPE。

Task Format

任务格式

markdown
---
skill: task-breakdown
version: 1
date: {{today}}
status: draft
---
markdown
---
skill: task-breakdown
version: 1
date: {{today}}
status: draft
---

Task [N]: [Title]

Task [N]: [Title]

Depends on: [Task numbers this requires, or "None"]
Outcome: [What exists when done - one sentence]
Why: [What this unblocks]
Acceptance: [How to verify - specific test, expected result]
Autonomy: AFK | HITL Why HITL: [only if HITL — what specific judgment is needed]
Human action: [External setup needed, if any]
undefined
Depends on: [Task numbers this requires, or "None"]
Outcome: [What exists when done - one sentence]
Why: [What this unblocks]
Acceptance: [How to verify - specific test, expected result]
Autonomy: AFK | HITL Why HITL: [only if HITL — what specific judgment is needed]
Human action: [External setup needed, if any]
undefined

Sizing Rules

规模规则

Right size:
  • Changes ONE testable thing
  • 5-30 min agent implementation time
  • Failure cause is obvious and isolated
Split if:
  • Multiple independent things to test
  • Multiple files for different reasons
  • Acceptance has multiple unrelated conditions
合适的任务规模：
  • 仅变更一项可测试内容
  • Agent实现时间为5-30分钟
  • 失败原因明确且独立
需拆分的情况：
  • 包含多个独立的可测试内容
  • 涉及多个用途不同的文件
  • 验收标准包含多个不相关条件

Autonomy Classification

自主性分类

Every task gets an Autonomy label:
LabelMeaningWhen to use
AFKAgent can execute end-to-end without human judgmentDeterministic tasks: scaffolding, CRUD, tests, migrations with clear schema
HITLNeeds human judgment during executionTaste decisions, external approvals, ambiguous acceptance criteria, security-sensitive changes
Default to AFK. Only mark HITL when the task genuinely requires a judgment call that the agent can't make from the spec alone. Every HITL task must state what specific judgment is needed — "needs review" is not sufficient.
Why this matters: Orchestrators (navigate, multi-agent systems) use this to batch-run AFK tasks autonomously and queue HITL tasks for user attention. Mislabeling AFK as HITL wastes the user's time. Mislabeling HITL as AFK risks wrong decisions.
每个任务需标记Autonomy标签：
标签含义适用场景
AFKAgent可端到端执行，无需人工判断确定性任务：脚手架搭建、CRUD操作、测试、schema明确的迁移
HITL执行过程中需要人工判断风格决策、外部审批、模糊的验收标准、安全敏感变更
默认使用AFK标签。仅当任务确实需要Agent无法仅从规格中获取的判断时，才标记为HITL。每个HITL任务必须说明具体需要何种判断——仅标注「需要评审」并不足够。
重要性： 编排器（navigate、多Agent系统）会利用该标签批量自动运行AFK任务，并将HITL任务排入队列等待用户关注。将AFK误标记为HITL会浪费用户时间；将HITL误标记为AFK则可能导致错误决策。

Content Rules

内容规则

Outcomes, not implementation.
Bad: "Create users table with id, email, created_at using Prisma" Good: "Database stores user records with unique emails and timestamps"
Risk-first ordering. Put uncertain/complex tasks early. Fail fast on hard problems.
Dependencies explicit. Every task lists what it needs. Enables parallel work and failure impact analysis.
聚焦成果，而非实现方式。
错误示例："使用Prisma创建包含id、email、created_at的用户表" 正确示例："数据库存储带有唯一邮箱和时间戳的用户记录"
风险优先排序。 将不确定/复杂的任务前置。尽早在难题上失败。
明确依赖关系。 每个任务需列出所需依赖。支持并行工作和失败影响分析。

Phase 2: Task Execution

第二阶段：任务执行

Before Starting

开始前准备

  1. Read architecture doc fully
  2. Read task list fully
  3. Understand the end state before writing code
  4. If anything is ambiguous, ask — assumptions cause rework.
  1. 完整阅读架构文档
  2. 完整阅读任务列表
  3. 编写代码前明确最终状态
  4. 若存在模糊内容，及时询问——假设会导致返工。

Per-Task Protocol

单任务执行流程

  1. State which task you're starting
  2. Write minimum code to pass acceptance
  3. State exactly what to test and expected result
  4. AFK tasks: Run the acceptance test. Pass → commit and move to the next task without waiting. Fail → fix and re-test (max 2 attempts, then flag to user).
  5. HITL tasks: Stop and present the result. Wait for user confirmation. Pass → commit, announce next task. Fail → fix the specific issue only, don't expand scope.
  1. 声明当前开始执行的任务
  2. 编写满足验收标准的最简代码
  3. 明确说明测试内容和预期结果
  4. AFK任务： 运行验收测试。通过→提交代码并直接进入下一个任务。失败→修复并重新测试（最多尝试2次，之后标记给用户）。
  5. HITL任务： 停止执行并展示结果。等待用户确认。通过→提交代码，宣布下一个任务。失败→仅修复指定问题，不得扩大范围。

Coding Rules

编码规则

Do:
  • Write absolute minimum code required
  • Focus only on current task
  • Keep code modular and testable
  • Preserve existing functionality
Avoid — these cause scope creep and breakage:
  • Sweeping changes across unrelated files
  • Touching unrelated code
  • Refactoring unless the task requires it
  • Adding features not in the current task
  • Premature optimization
When human action is needed:
  • State exactly what to do and which file/value to update
  • Wait for confirmation before continuing
建议做：
  • 编写满足要求的最简代码
  • 仅聚焦当前任务
  • 保持代码模块化和可测试性
  • 保留现有功能
需避免——这些会导致范围蔓延和故障：
  • 对无关文件进行大范围修改
  • 触碰无关代码
  • 除非任务要求，否则不进行重构
  • 添加当前任务未包含的功能
  • 过早优化
当需要人工操作时：
  • 明确说明需执行的操作及需更新的文件/值
  • 等待确认后再继续

When Stuck

遇到阻塞时的处理

  1. It is better to stop and say "I'm stuck — here's what I've tried" than to keep attempting fixes that aren't working. Bad work is worse than no work.
  2. State what's blocking
  3. Propose smallest modification to unblock
  4. Wait for approval
  1. 与其继续尝试无效修复，不如停止并说明「我遇到了阻塞——以下是我已尝试的方法」。错误的工作比不做更糟。
  2. 说明阻塞原因
  3. 提出最小化的修改建议以解除阻塞
  4. 等待批准

Scope Change Protocol

范围变更流程

If you discover a missing requirement:
  1. Stop current task
  2. State what's missing and why it's needed
  3. Propose where it fits in task order
  4. Wait for PM to update task list
  5. Resume only after task list is updated
若发现缺失的需求：
  1. 停止当前任务
  2. 说明缺失内容及其必要性
  3. 提出其在任务顺序中的合适位置
  4. 等待产品经理更新任务列表
  5. 仅在任务列表更新后恢复执行

Anti-Patterns

反模式

Anti-PatternProblemINSTEAD
"Build the auth system"5+ tasks disguised as onedecomposer-agent splits into registration, login, middleware, reset, verification
"Create the Button component"Not independently testableCombine with click handling and visual states
Hidden dependencyTask 8 needs API key not mentioned until Task 8dependency-mapper-agent surfaces it; goes in Prerequisites
"User flow works correctly"Vague acceptance — means different things to everyoneacceptance-agent writes specific action + input + expected result
Implementation-as-outcome"Use Redux for state management" dictates HOWdecomposer-agent writes WHAT: "User data fetches efficiently with caching"
Saving integrations for the endIntegration issues discovered late cause the most reworkordering-agent front-loads risky integration work
反模式问题正确做法
"构建认证系统"将5+个任务伪装成一个decomposer-agent将其拆分为注册、登录、中间件、重置、验证等任务
"创建Button组件"无法独立测试与点击处理和视觉状态合并为一个任务
隐藏依赖任务8需要的API密钥直到任务8才提及dependency-mapper-agent提前发现，并将其纳入前置条件
"用户流程正常工作"验收标准模糊——不同人理解不同acceptance-agent编写具体的操作+输入+预期结果
以实现方式为成果"使用Redux进行状态管理"指定了实现方式decomposer-agent编写成果："用户数据可高效获取并缓存"
将集成工作留到最后后期发现集成问题会导致大量返工ordering-agent将高风险集成工作前置

Worked Example

示例

User: "Break down a Todo app with Supabase auth and email notifications."
Orchestrator confirms: LOCKED SCOPE (spec is clear).
Layer 1 dispatch (parallel):
  • decomposer-agent
    → produces 7 tasks: scaffold, signup, login + protected routes, tasks table + RLS, create task, email notification, end-to-end test
  • dependency-mapper-agent
    → identifies fan-out from scaffold (signup, login, tasks table are parallel), fan-in at create task (needs auth + schema), hidden dep: Resend API key missing from prerequisites
Layer 2 chain:
  • ordering-agent
    → merges: moves Resend API key to Prerequisites, orders risk-first (auth before CRUD), identifies parallelism (signup and tasks table can run simultaneously)
  • acceptance-agent
    → writes: "Submit signup form → user appears in Supabase Auth → confirmation email sent" for Task 2
  • critic-agent
    → PASS, all 6 gates pass
Artifact saved to 
.agents/tasks.md
.
用户： "分解一个带有Supabase认证和邮件通知的Todo应用。"
编排器确认： LOCKED SCOPE（规格明确）。
第一层并行调度：
  • decomposer-agent
    → 生成7个任务：脚手架搭建、注册、登录+受保护路由、任务表+RLS、创建任务、邮件通知、端到端测试
  • dependency-mapper-agent
    → 识别出脚手架的扇出依赖（注册、登录、任务表可并行执行），创建任务的扇入依赖（需要认证+ schema），以及隐藏依赖：前置条件中缺少Resend API密钥
第二层串行流程：
  • ordering-agent
    → 合并结果：将Resend API密钥移至前置条件，按风险优先排序（认证优先于CRUD），识别并行性（注册和任务表可同时执行）
  • acceptance-agent
    → 编写验收标准："提交注册表单→用户出现在Supabase Auth中→发送确认邮件"（任务2）
  • critic-agent
    → PASS，所有6个gate均通过
工件保存至
.agents/tasks.md
。

PM Feedback Format

产品经理反馈格式

When reporting test results:
Task [N]: PASS | FAIL | BLOCKED

[If FAIL]: What broke, error message, steps to reproduce
[If BLOCKED]: What's preventing test
报告测试结果时：
Task [N]: PASS | FAIL | BLOCKED

[若FAIL]: 故障内容、错误信息、复现步骤
[若BLOCKED]: 阻塞测试的原因

Artifact Template

工件模板

On re-run: rename existing artifact to 
tasks.v[N].md
and create new with incremented version.
Save to 
.agents/tasks.md
using the Task Format above.
重新运行时：将现有工件重命名为
tasks.v[N].md
，并创建新版本的工件。
按照上述任务格式保存至
.agents/tasks.md
。

Next Step

下一步

Tasks are ready. Begin implementation of the first unblocked task. Run 
review-chain
after each major task completion. Run 
ship
when all tasks are done.
任务已准备就绪。开始执行第一个未阻塞的任务。完成每个主要任务后运行
review-chain
。所有任务完成后运行
ship
。

References

参考资料

  • references/sizing-examples.md — Right-sized vs wrong-sized tasks with split/combine guidance
  • references/dependency-patterns.md — Common dependency patterns, visualization, and hidden dependency detection
  • references/acceptance-criteria.md — Acceptance criteria templates by task type
  • references/sizing-examples.md —— 任务规模合适与不合适的示例，及拆分/合并指导
  • references/dependency-patterns.md —— 常见依赖模式、可视化及隐藏依赖检测
  • references/acceptance-criteria.md —— 按任务类型分类的验收标准模板