task-decomposition

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Task Decomposition

任务分解

Overview

概述

Task decomposition breaks complex tasks into manageable, well-defined subtasks with clear dependencies, effort estimates, and parallelization opportunities. It covers hierarchical work breakdown structures (WBS), dependency graph construction, critical path analysis, task sizing, and identification of concurrent execution opportunities. Essential for planning multi-step implementations, project estimation, and autonomous loop task selection.

Announce at start: "I'm using the task-decomposition skill to break this work into a structured hierarchy with dependencies and estimates."

任务分解将复杂任务拆分为可管理、定义清晰的子任务，附带明确的依赖关系、工作量估算和并行执行空间。覆盖分层工作分解结构（WBS）、依赖图构建、关键路径分析、任务规模评估以及并发执行机会识别，是多步骤实现规划、项目估算、自治循环任务选择的核心能力。

启动时宣告： "我将使用task-decomposition技能将这项工作拆分为带有依赖关系和估算值的结构化层级。"

Trigger Conditions

触发条件

Complex task needs to be broken into subtasks
Dependency mapping is needed between work items
Effort estimation is required for planning
Parallelization opportunities need to be identified
```
/decompose
```
command invoked
Transition from planning skill for complex plans
Autonomous loop needs task selection guidance

复杂任务需要拆分为子任务
工作项之间需要做依赖映射
规划需要工作量估算支撑
需要识别可并行执行的机会
触发了
```
/decompose
```
命令
从planning技能流转过来的复杂规划需求
自治循环需要任务选择指引

Phase 1: Scope Definition

阶段1：范围定义

Goal: Define clear boundaries for the decomposition.

Define the overall deliverable and acceptance criteria
Identify the boundaries (what is in scope, what is not)
Determine the decomposition granularity level
Identify stakeholders and their requirements
Establish constraints (time, resources, dependencies)

目标： 明确任务分解的边界。

定义整体交付物和验收标准
识别边界（范围内、范围外的内容）
确定分解的粒度级别
识别利益相关方及其需求
明确约束条件（时间、资源、依赖）

Granularity Decision Table

粒度决策表

Context	Target Level	Typical Duration	Rationale
Autonomous loop (Ralph)	L3-L4 (Task/Subtask)	15 min - 4 hours	ONE task per loop iteration
Sprint planning	L2-L3 (Story/Task)	0.5-2 days	Sprint-sized work items
Roadmap planning	L0-L1 (Epic/Feature)	2-8 weeks	High-level milestone tracking
Bug fix	L3-L4 (Task/Subtask)	15 min - 2 hours	Focused, specific fixes

场景	目标级别	典型时长	逻辑
自治循环（Ralph）	L3-L4（任务/子任务）	15分钟 - 4小时	每个循环迭代处理1个任务
Sprint规划	L2-L3（用户故事/任务）	0.5-2天	符合Sprint规模的工作项
路线图规划	L0-L1（史诗/特性）	2-8周	高层级里程碑追踪
Bug修复	L3-L4（任务/子任务）	15分钟 - 2小时	聚焦的针对性修复

Granularity Levels

粒度级别定义

Level	Name	Typical Duration	Example
L0	Epic	2-8 weeks	"User authentication system"
L1	Feature	2-5 days	"OAuth2 login flow"
L2	Story	0.5-2 days	"Google OAuth provider integration"
L3	Task	1-4 hours	"Implement Google callback handler"
L4	Subtask	15-60 minutes	"Parse OAuth token response"

STOP — Do NOT proceed to Phase 2 until:

Deliverable and acceptance criteria are defined
Scope boundaries are clear (in/out)
Target granularity level is chosen
Constraints are identified

级别	名称	典型时长	示例
L0	史诗（Epic）	2-8周	"用户认证系统"
L1	特性（Feature）	2-5天	"OAuth2登录流程"
L2	用户故事（Story）	0.5-2天	"Google OAuth提供商集成"
L3	任务（Task）	1-4小时	"实现Google回调处理逻辑"
L4	子任务（Subtask）	15-60分钟	"解析OAuth令牌响应"

停止检查 — 满足以下条件后才可进入阶段2：

已定义交付物和验收标准
范围边界清晰（明确范围内外内容）
已选定目标粒度级别
已识别约束条件

Phase 2: Hierarchical Breakdown

阶段2：分层拆解

Goal: Decompose the work into a tree structure meeting the INVEST criteria.

Identify top-level work streams (epics or major components)
Break each work stream into features or milestones
Decompose features into implementable tasks
Apply the "2-hour rule" — no task should exceed 2 hours of focused work
Ensure each task has a clear definition of done
Verify MECE (Mutually Exclusive, Collectively Exhaustive) coverage

目标： 将工作拆分为符合INVEST标准的树状结构。

识别顶层工作流（史诗或核心组件）
将每个工作流拆分为特性或里程碑
将特性拆解为可落地的任务
遵守「2小时规则」—— 任何任务的专注工作时长不应超过2小时
确保每个任务有清晰的完成定义
验证MECE（相互独立、完全穷尽）覆盖度

The INVEST Criteria for Tasks

任务的INVEST标准

Criterion	Question	Bad Example	Good Example
Independent	Can this be done without waiting for others?	"Implement auth after DB is ready"	"Implement auth with mock DB"
Negotiable	Is the approach flexible?	"Use Redis for caching"	"Add caching layer for user sessions"
Valuable	Does completing this deliver value?	"Set up folder structure"	"Create user registration endpoint"
Estimable	Can you estimate the effort?	"Improve performance"	"Add database index for user lookup query"
Small	Can one person finish it in < 2 hours?	"Build the dashboard"	"Create dashboard chart component for revenue data"
Testable	Can you verify it is done?	"Make it better"	"Response time < 200ms for /api/users"

标准	校验问题	反面示例	正面示例
Independent（独立）	该任务无需等待其他任务即可完成吗？	"数据库就绪后实现认证功能"	"基于Mock DB实现认证功能"
Negotiable（可协商）	实现方式是否灵活？	"必须使用Redis做缓存"	"为用户会话添加缓存层"
Valuable（有价值）	完成该任务能交付价值吗？	"搭建文件夹结构"	"开发用户注册接口"
Estimable（可估算）	可以估算工作量吗？	"提升性能"	"为用户查询请求添加数据库索引"
Small（小体量）	单人可以在2小时内完成吗？	"搭建整个看板"	"开发营收数据的看板图表组件"
Testable（可测试）	可以验证是否完成吗？	"优化体验"	`/api/users` 接口响应时间<200ms

MECE Verification

MECE校验

Check	Question
Mutually Exclusive	Does any task overlap with another? (Should not)
Collectively Exhaustive	Do all tasks together cover the full deliverable? (Should)
No orphans	Does every task contribute to the deliverable?
No gaps	Is there any work needed that has no task?

STOP — Do NOT proceed to Phase 3 until:

All work streams are identified
Tasks meet INVEST criteria
MECE coverage is verified
No task exceeds 2 hours

校验项	校验问题
相互独立	是否存在任务重叠？（不应存在）
完全穷尽	所有任务加起来是否覆盖了完整的交付物？（应该覆盖）
无孤立任务	每个任务都对交付物有贡献吗？
无缺口	是否有需要完成但未对应任务的工作？

停止检查 — 满足以下条件后才可进入阶段3：

已识别所有工作流
所有任务符合INVEST标准
已验证MECE覆盖度
无超过2小时的任务

Phase 3: Dependency Mapping

阶段3：依赖映射

Goal: Build a directed acyclic graph (DAG) of task dependencies.

Identify input/output dependencies between tasks
Classify dependency types
Build a directed acyclic graph (DAG)
Identify the critical path (longest dependency chain)
Flag circular dependencies as errors to resolve
Mark external dependencies (API access, approvals, third-party)

目标： 构建任务依赖的有向无环图（DAG）。

识别任务之间的输入/输出依赖
对依赖类型进行分类
构建有向无环图（DAG）
识别关键路径（最长的依赖链）
将循环依赖标记为待解决的错误
标记外部依赖（API访问、审批、第三方服务等）

Dependency Types

依赖类型

Type	Symbol	Meaning	Example
Finish-to-Start (FS)	A -> B	B cannot start until A finishes	"Deploy" after "Build passes"
Start-to-Start (SS)	A => B	B can start when A starts	"Write docs" when "Write code" starts
Finish-to-Finish (FF)	A =>> B	B cannot finish until A finishes	"Testing" finishes after "Development"
Start-to-Finish (SF)	A ~> B	B cannot finish until A starts	Rare — shift handoff scenarios

类型	符号	含义	示例
完成-开始（FS）	A -> B	A完成前B无法启动	"构建通过"后才能"部署"
开始-开始（SS）	A => B	A启动后B即可启动	"写代码"启动后即可开始"写文档"
完成-完成（FF）	A =>> B	A完成前B无法完成	"测试"需在"开发"完成后结束
开始-完成（SF）	A ~> B	A启动前B无法完成	罕见 — 换班交接场景

Dependency Notation Format

依赖标注格式

Task 1: Set up database schema
Task 2: Create data access layer         [depends: 1]
Task 3: Implement API endpoints          [depends: 2]
Task 4: Write unit tests for DAL         [depends: 2]
Task 5: Write API integration tests      [depends: 3, 4]
Task 6: Create frontend components       [depends: none]
Task 7: Connect frontend to API          [depends: 3, 6]
Task 8: End-to-end testing               [depends: 5, 7]

Parallel tracks:
  Track A: 1 -> 2 -> 3 -> 5 -> 8
  Track B: 1 -> 2 -> 4 -> 5 -> 8
  Track C: 6 -> 7 -> 8
  Critical path: 1 -> 2 -> 3 -> 7 -> 8

Task 1: Set up database schema
Task 2: Create data access layer         [depends: 1]
Task 3: Implement API endpoints          [depends: 2]
Task 4: Write unit tests for DAL         [depends: 2]
Task 5: Write API integration tests      [depends: 3, 4]
Task 6: Create frontend components       [depends: none]
Task 7: Connect frontend to API          [depends: 3, 6]
Task 8: End-to-end testing               [depends: 5, 7]

Parallel tracks:
  Track A: 1 -> 2 -> 3 -> 5 -> 8
  Track B: 1 -> 2 -> 4 -> 5 -> 8
  Track C: 6 -> 7 -> 8
  Critical path: 1 -> 2 -> 3 -> 7 -> 8

Circular Dependency Resolution

循环依赖解决方法

Detection	Resolution
A depends on B, B depends on A	Break into smaller tasks that remove the cycle
A depends on B's interface, B depends on A's interface	Define interfaces first as a separate task
Tight coupling between components	Introduce an abstraction layer task

STOP — Do NOT proceed to Phase 4 until:

All dependencies are mapped
No circular dependencies exist
Critical path is identified
External dependencies are flagged

检测场景	解决方案
A依赖B，B依赖A	拆分为更小的任务消除循环
A依赖B的接口，B依赖A的接口	新增单独的接口定义任务
组件间紧耦合	新增抽象层开发任务

停止检查 — 满足以下条件后才可进入阶段4：

已映射所有依赖
无循环依赖
已识别关键路径
已标记所有外部依赖

Phase 4: Parallelization Planning

阶段4：并行规划

Goal: Identify independent task clusters that can run concurrently.

Identify independent task clusters (no dependencies between them)
Group tasks by resource type (read, write, build, test)
Determine maximum parallelism based on resource constraints
Sequence tasks within each parallel track
Plan synchronization points (merge gates)

目标： 识别可并发执行的独立任务集群。

识别独立任务集群（相互无依赖）
按资源类型（读、写、构建、测试）分组任务
根据资源约束确定最大并行度
为每个并行轨道内的任务排序
规划同步点（合并关口）

Resource-Based Parallelism Limits

基于资源的并行上限

Resource Type	Max Parallel	Rationale
Code reading / analysis	Unlimited	No side effects
File creation / editing	3-5	Avoid merge conflicts
Build / compile	1	Resource contention
Test execution	1-2	Shared state, ports
Database migrations	1	Sequential by nature
Documentation	Unlimited	Independent files

资源类型	最大并行度	逻辑
代码阅读/分析	无限制	无副作用
文件创建/编辑	3-5	避免合并冲突
构建/编译	1	资源争抢
测试执行	1-2	共享状态、端口冲突
数据库迁移	1	天然需要串行
文档编写	无限制	独立文件

Parallelization Pattern Decision Table

并行模式决策表

Pattern	When to Use	Example
Independent Clusters	Work streams with no shared state	Backend, Frontend, Infra
By Layer	Layers touch different files	API, Service, Data
By Feature Area	Independent vertical slices	Auth, Profile, Billing
By Task Type	Code, tests, docs touch different files	Implement, Test, Document

模式	使用场景	示例
独立集群	无共享状态的工作流	后端、前端、基础设施
按层级拆分	不同层级对应不同文件	API层、服务层、数据层
按功能域拆分	独立的垂直切片	认证、个人中心、计费
按任务类型拆分	代码、测试、文档对应不同文件	实现、测试、文档编写

Synchronization Points

同步点示例

  +------+     +------+     +------+
  |Task A|     |Task B|     |Task C|
  +--+---+     +--+---+     +--+---+
     |            |            |
     v            v            v
  ======================================
     SYNC GATE: All Complete
     Verify: no conflicts, tests pass
  ======================================
                 |
                 v
          +----------+
          |Next Phase|
          +----------+

STOP — Do NOT proceed to Phase 5 until:

Independent clusters are identified
Resource constraints are considered
Synchronization points are defined
Maximum parallelism is determined

  +------+     +------+     +------+
  |Task A|     |Task B|     |Task C|
  +--+---+     +--+---+     +--+---+
     |            |            |
     v            v            v
  ======================================
     SYNC GATE: All Complete
     Verify: no conflicts, tests pass
  ======================================
                 |
                 v
          +----------+
          |Next Phase|
          +----------+

停止检查 — 满足以下条件后才可进入阶段5：

已识别独立集群
已考虑资源约束
已定义同步点
已确定最大并行度

Phase 5: Estimation and Prioritization

阶段5：估算与优先级排序

Goal: Estimate effort for each task and create an execution timeline.

目标： 估算每个任务的工作量，制定执行 timeline。

T-Shirt Sizing to Hours

T恤尺码与时长对应表

Size	Hours	Confidence	Example
XS	0.5-1h	High	Rename a variable, fix a typo
S	1-2h	High	Add a simple endpoint, write a test
M	2-4h	Medium	Implement a feature with known pattern
L	4-8h	Low	New feature with research needed
XL	8h+	Very Low	Must be decomposed further

尺码	时长	置信度	示例
XS	0.5-1小时	高	重命名变量、修复拼写错误
S	1-2小时	高	新增简单接口、编写测试用例
M	2-4小时	中	实现有已知模式的功能
L	4-8小时	低	需要调研的新功能
XL	8小时以上	极低	必须进一步拆解

Estimation Heuristics

估算启发规则

Scenario	Multiplier	Rationale
Known pattern	1.2x base estimate	20% buffer for unknowns
Unknown pattern	2x base estimate	Add research spike task first
Integration work	1.5x sum of components	Integration is harder than parts
First-time technology	3x "if I knew how" estimate	Learning curve
Bug fixes	Time-box 2h investigation	Then re-estimate

场景	乘数	逻辑
已知实现模式	基础估算 * 1.2	预留20%的未知风险缓冲
未知实现模式	基础估算 * 2	先新增调研任务
集成工作	组件估算总和 * 1.5	集成难度高于单个组件
首次使用的技术	「熟悉技术的估算值」 * 3	学习曲线成本
Bug修复	2小时时间盒调研	调研后重新估算

Three-Point Estimation

三点估算法

Expected = (Optimistic + 4 * Most Likely + Pessimistic) / 6

Example:
  Optimistic:  2 hours (everything goes smoothly)
  Most Likely: 4 hours (normal development pace)
  Pessimistic: 10 hours (major unexpected issues)
  Expected:    (2 + 16 + 10) / 6 = 4.7 hours

Expected = (Optimistic + 4 * Most Likely + Pessimistic) / 6

Example:
  Optimistic:  2 hours (everything goes smoothly)
  Most Likely: 4 hours (normal development pace)
  Pessimistic: 10 hours (major unexpected issues)
  Expected:    (2 + 16 + 10) / 6 = 4.7 hours

Prioritization Decision Table

优先级决策表

Factor	Weight	How to Evaluate
On critical path	Highest	Delays here delay everything
Blocks other tasks	High	Unblocking multiplies throughput
Business value	High	User-facing impact
Risk reduction	Medium	De-risks unknowns early
Quick win	Medium	Low effort, high morale
Nice to have	Low	Only after core work is done

因素	权重	评估方式
属于关键路径	最高	此处延迟会导致整体延期
阻塞其他任务	高	解除阻塞可大幅提升吞吐量
业务价值	高	对用户的影响程度
风险降低	中	提前消除未知风险
快速胜利	中	低投入、高士气价值
锦上添花	低	核心工作完成后再处理

Work Breakdown Structure Template

工作分解结构模板

markdown

undefined

markdown

undefined

WBS: [Project Name]

1. [Work Stream A]

1.1 [Feature]

1.1.1 [Task] — Est: 2h — Deps: none — Priority: P0
1.1.2 [Task] — Est: 1h — Deps: 1.1.1 — Priority: P0
1.1.3 [Task] — Est: 3h — Deps: 1.1.1 — Priority: P1

1.1.1 [Task] — Est: 2h — Deps: none — Priority: P0
1.1.2 [Task] — Est: 1h — Deps: 1.1.1 — Priority: P0
1.1.3 [Task] — Est: 3h — Deps: 1.1.1 — Priority: P1

1.2 [Feature]

1.2.1 [Task] — Est: 1h — Deps: none — Priority: P0
1.2.2 [Task] — Est: 2h — Deps: 1.2.1, 1.1.2 — Priority: P1

1.2.1 [Task] — Est: 1h — Deps: none — Priority: P0
1.2.2 [Task] — Est: 2h — Deps: 1.2.1, 1.1.2 — Priority: P1

2. [Work Stream B]

2.1 [Feature]

2.1.1 [Task] — Est: 1h — Deps: none — Priority: P0
2.1.2 [Task] — Est: 4h — Deps: 2.1.1 — Priority: P0

2.1.1 [Task] — Est: 1h — Deps: none — Priority: P0
2.1.2 [Task] — Est: 4h — Deps: 2.1.1 — Priority: P0

Summary

Total tasks: N
Estimated total effort: Xh
Critical path duration: Yh
Max parallelism: Z tracks
External dependencies: [list]

---

Total tasks: N
Estimated total effort: Xh
Critical path duration: Yh
Max parallelism: Z tracks
External dependencies: [list]

---

Critical Path Analysis

关键路径分析

How to Find the Critical Path

如何找到关键路径

List all tasks with durations and dependencies
Forward pass: calculate earliest start (ES) and earliest finish (EF)
Backward pass: calculate latest start (LS) and latest finish (LF)
Float = LS - ES (tasks with zero float are on the critical path)
The critical path is the longest chain through the dependency graph

列出所有任务的时长和依赖
正向推演：计算最早开始时间（ES）和最早完成时间（EF）
反向推演：计算最晚开始时间（LS）和最晚完成时间（LF）
浮动时间 = LS - ES（浮动时间为0的任务属于关键路径）
关键路径是依赖图中最长的任务链

Optimization Strategies

优化策略

Strategy	When	Effect	Risk
Parallelize	Independent tasks on critical path	Reduces calendar time	Low
Fast-track	Overlap sequential tasks	Reduces duration	Medium — may cause rework
Crash	Add resources to critical tasks	Reduces duration	Medium — coordination cost
Scope reduction	Remove non-essential tasks	Reduces total work	Low — if non-essential is correct
Spike first	Unknown tasks blocking the path	De-risks estimates	Low

策略	适用场景	效果	风险
并行化	关键路径上的独立任务	减少日历时长	低
快速跟进	重叠串行任务	缩短周期	中 — 可能导致返工
赶工	为关键路径任务增加资源	缩短周期	中 — 协调成本上升
范围缩减	移除非核心任务	减少总工作量	低 — 确认非核心判断正确
先行调研	阻塞路径的未知任务	降低估算风险	低

Anti-Patterns / Common Mistakes

反模式/常见错误

Anti-Pattern	Why It Fails	Correct Approach
Tasks too large to estimate	"Build the backend" is not a task	Decompose until estimable (< 2h)
Missing dependencies	Surface during implementation, cause rework	Map ALL dependencies upfront
Circular dependencies	Indicate unclear architecture	Break the cycle with interface tasks
All tasks sequential	No parallelism possible	Identify independent clusters
Estimation without decomposition	Guessing at L0 level, always wrong	Estimate at leaf level, sum up
Ignoring external dependencies	Block progress unexpectedly	Flag and plan for them
Over-decomposition	Noise, not signal (50 subtasks for a form)	Stop at meaningful, testable units
Ignoring critical path	Priorities work on non-critical tasks	Always prioritize critical path
Not re-estimating	Estimates drift as you learn	Re-estimate after each phase
Tasks without acceptance criteria	Cannot verify completion	Every task has definition of done

反模式	失效原因	正确做法
任务过大无法估算	"搭建后端"不是一个合格任务	拆解到可估算的粒度（<2小时）
遗漏依赖	执行阶段才暴露，导致返工	提前映射所有依赖
循环依赖	说明架构不清晰	通过接口定义任务打破循环
所有任务串行	无法利用并行能力	识别独立任务集群
未拆解就估算	在L0级别猜测，几乎必然错误	对叶子节点估算后汇总
忽略外部依赖	意外阻塞进度	提前标记并规划应对
过度拆解	产生噪音无实际价值（一个表单拆50个子任务）	停在有意义、可测试的单元粒度
忽略关键路径	优先处理非关键任务	始终优先处理关键路径任务
不重新估算	随着信息增加估算偏差变大	每个阶段结束后重新估算
任务无验收标准	无法验证是否完成	每个任务都要有完成定义

Anti-Rationalization Guards

反侥幸守卫规则

<HARD-GATE> Do NOT skip dependency mapping. Do NOT leave tasks larger than 2 hours. Do NOT estimate without decomposing first. Every task must have dependencies, estimates, and acceptance criteria. </HARD-GATE>

If you catch yourself thinking:

"I can estimate the whole thing without breaking it down..." — No. Decompose first.
"Dependencies are obvious, I don't need to map them..." — Map them. Hidden dependencies cause failures.
"This task is fine at 8 hours..." — Decompose it. XL tasks must be broken down.
"The critical path doesn't matter for small projects..." — It does. It tells you what to prioritize.

<HARD-GATE> 不得跳过依赖映射。不得保留超过2小时的任务。不得未拆解就进行估算。每个任务必须有依赖、估算值和验收标准。 </HARD-GATE>

如果你发现自己有以下想法：

"我不用拆解就能估算整个项目的工作量..." — 不行，先拆解。
"依赖很明显，我不用专门映射..." — 必须映射，隐藏依赖是失败的主要原因。
"这个8小时的任务没问题..." — 必须拆解，XL级任务必须拆分。
"小项目不用考虑关键路径..." — 有必要，关键路径告诉你优先级最高的任务。

Subagent Dispatch Opportunities

子Agent调度机会

Task Pattern	Dispatch To	When
Parallelizable leaf tasks identified during decomposition	Parallel subagents via `Agent` tool	When tasks have no shared dependencies
Architecture analysis of task boundaries	`planner` agent	When decomposition reveals cross-cutting concerns
Validation of decomposition completeness	`spec-reviewer` agent	When task tree is complete but unverified

Mark each decomposed task with a

parallelizable: yes/no

flag in the output table. Follow the

dispatching-parallel-agents

skill protocol when dispatching.

任务模式	调度对象	触发时机
拆解过程中识别到的可并行叶子任务	通过 `Agent` 工具调度并行子Agent	任务无共享依赖时
任务边界的架构分析	`planner` agent	拆解过程中发现跨领域问题时
拆解完整性校验	`spec-reviewer` agent	任务树已完成但未验证时

在输出表格中为每个拆解后的任务标记

parallelizable: yes/no

标识。调度时遵循

dispatching-parallel-agents

技能协议。

Integration Points

集成点

Skill	Relationship	When
`planning`	Upstream — provides the plan to decompose	Complex plans need WBS
`task-management`	Downstream — receives decomposed tasks	For execution tracking
`dispatching-parallel-agents`	Downstream — receives parallelizable clusters	For concurrent execution
`autonomous-loop`	Downstream — task selection from WBS	Ralph task selection
`executing-plans`	Downstream — batch creation from WBS	Plan execution
`subagent-driven-development`	Downstream — independent tasks for subagents	Delegated implementation
`spec-writing`	Complementary — specs inform decomposition	Understanding requirements

技能	关系	触发时机
`planning`	上游 — 提供待拆解的规划	复杂规划需要生成WBS时
`task-management`	下游 — 接收拆解后的任务	用于执行追踪时
`dispatching-parallel-agents`	下游 — 接收可并行的任务集群	用于并发执行时
`autonomous-loop`	下游 — 从WBS中选择任务	Ralph选择任务时
`executing-plans`	下游 — 从WBS生成批量任务	计划执行时
`subagent-driven-development`	下游 — 接收子Agent可处理的独立任务	委托实现时
`spec-writing`	互补 — 规格说明支撑拆解	理解需求时

Concrete Examples

具体示例

Example: Decomposition of "Add User Authentication"

示例："新增用户认证"功能拆解

undefined

undefined

WBS: User Authentication

1. Core Auth

1.1 Token Management

1.1.1 Implement JWT generation — Est: 1h — Deps: none — P0
1.1.2 Implement JWT validation — Est: 1h — Deps: 1.1.1 — P0
1.1.3 Implement refresh token rotation — Est: 2h — Deps: 1.1.2 — P1

1.1.1 Implement JWT generation — Est: 1h — Deps: none — P0
1.1.2 Implement JWT validation — Est: 1h — Deps: 1.1.1 — P0
1.1.3 Implement refresh token rotation — Est: 2h — Deps: 1.1.2 — P1

1.2 Auth Middleware

1.2.1 Create auth middleware — Est: 1h — Deps: 1.1.2 — P0
1.2.2 Add role-based access control — Est: 2h — Deps: 1.2.1 — P1

1.2.1 Create auth middleware — Est: 1h — Deps: 1.1.2 — P0
1.2.2 Add role-based access control — Est: 2h — Deps: 1.2.1 — P1

2. Auth Endpoints

2.1 Registration

2.1.1 POST /auth/register endpoint — Est: 1h — Deps: 1.1.1 — P0
2.1.2 Email validation — Est: 30m — Deps: none — P0

2.1.1 POST /auth/register endpoint — Est: 1h — Deps: 1.1.1 — P0
2.1.2 Email validation — Est: 30m — Deps: none — P0

2.2 Login

2.2.1 POST /auth/login endpoint — Est: 1h — Deps: 1.1.1, 1.2.1 — P0
2.2.2 POST /auth/refresh endpoint — Est: 1h — Deps: 1.1.3 — P1

2.2.1 POST /auth/login endpoint — Est: 1h — Deps: 1.1.1, 1.2.1 — P0
2.2.2 POST /auth/refresh endpoint — Est: 1h — Deps: 1.1.3 — P1

Summary

Total tasks: 8
Estimated total effort: 10.5h
Critical path: 1.1.1 -> 1.1.2 -> 1.2.1 -> 2.2.1 (4h)
Max parallelism: 3 tracks (Token, Middleware, Endpoints)
External dependencies: none

---

Total tasks: 8
Estimated total effort: 10.5h
Critical path: 1.1.1 -> 1.1.2 -> 1.2.1 -> 2.2.1 (4h)
Max parallelism: 3 tracks (Token, Middleware, Endpoints)
External dependencies: none

---

Skill Type

技能类型

RIGID — Follow the decomposition phases in order. Every task must meet the INVEST criteria and have explicit dependencies, estimates, and acceptance criteria. The dependency graph and critical path analysis are mandatory for multi-day work.

严格型（RIGID） — 按顺序遵循拆解阶段。每个任务必须符合INVEST标准，且有明确的依赖、估算值和验收标准。多天工作量的任务必须完成依赖图和关键路径分析。