task-decomposition
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseTask Decomposition Diagnostic
任务分解诊断
Transform overwhelming development tasks into manageable units by respecting cognitive limits, creating clear boundaries, and enabling parallel work. Tasks properly decomposed achieve 3x higher completion rates and 60% fewer defects.
通过遵循认知极限、创建清晰边界并支持并行工作，将繁重的开发任务转化为可管理的单元。经过合理分解的任务完成率可提高3倍，缺陷减少60%。
When to Use This Skill
何时使用此技能
Use this skill when:
- A task feels too big to estimate
- Unsure where to start
- Blocked by dependencies
- Task keeps growing (scope creep)
- Need to break down an epic or feature
Do NOT use this skill when:
- Task is already small and clear
- Doing implementation work
- Architecture decisions needed (use system-design)
在以下场景使用此技能：
- 任务大到无法估算
- 不确定从哪里开始
- 被依赖关系阻塞
- 任务持续膨胀（范围蔓延）
- 需要拆分史诗级需求或功能
请勿在以下场景使用此技能：
- 任务已经小而清晰
- 正在进行实现工作
- 需要做架构决策（使用system-design技能）
Core Principle
核心原则
The goal isn't more tasks—it's the right tasks. Tasks small enough to understand completely, large enough to deliver value, independent enough to avoid blocking.
目标不是更多任务——而是合适的任务。 任务要小到能完全理解，大到能交付价值，独立到避免阻塞。
Quick Reference: Cognitive Limits
快速参考：认知极限
| Limit | Threshold | Implication |
|---|---|---|
| Working memory | 7±2 items | Max concepts per task |
| Context switch recovery | 23 minutes | Minimize task switching |
| Files examined | 15-20 max | Bound task scope |
| Days before completion drops | 2-3 days | Keep tasks under this |
| 极限 | 阈值 | 含义 |
|---|---|---|
| 工作记忆 | 7±2 项 | 每个任务最多包含的概念数 |
| 上下文切换恢复时间 | 23分钟 | 尽量减少任务切换 |
| 检查的文件数 | 最多15-20个 | 限定任务范围 |
| 完成率下降前的天数 | 2-3天 | 任务时长控制在此范围内 |
Task Duration Success Rates
任务时长与完成率
| Duration | Completion Rate |
|---|---|
| < 2 hours | 95% |
| 2-4 hours | 90% |
| 4-8 hours (1 day) | 80% |
| 2-3 days | 60% |
| 1 week | 35% |
| > 2 weeks | <10% |
| 时长 | 完成率 |
|---|---|
| < 2小时 | 95% |
| 2-4小时 | 90% |
| 4-8小时（1天） | 80% |
| 2-3天 | 60% |
| 1周 | 35% |
| >2周 | <10% |
Diagnostic States
诊断状态
TD1: Too Big to Understand
TD1：大到无法理解
Symptoms: Estimates range wildly, can't hold all requirements in mind, more than 7 concepts to track
Interventions:
- Apply INVEST criteria: Independent, Negotiable, Valuable, Estimable, Small, Testable
- Use vertical slicing (each slice is independently deployable)
- Apply walking skeleton (minimal end-to-end first)
症状： 估算范围差异极大，无法记住所有需求，需要跟踪的概念超过7个
干预措施：
- 应用INVEST准则：Independent（独立）、Negotiable（可协商）、Valuable（有价值）、Estimable（可估算）、Small（小）、Testable（可测试）
- 使用vertical slicing（垂直切片）：每个切片可独立部署
- 应用walking skeleton（行走骨架）：先实现最小端到端流程
TD2: No Clear Entry Point
TD2：无明确切入点
Symptoms: Multiple valid starting points, paralysis, everything seems connected
Interventions:
- Front-load risk: start with highest-uncertainty items
- Tracer bullet: minimal proof of concept
- Find the walking skeleton: thinnest slice through all layers
症状： 有多个可行的起始点，陷入停滞，所有内容似乎相互关联
干预措施：
- 前置风险：从不确定性最高的项开始
- Tracer bullet（示踪弹）：最小化概念验证
- 找到walking skeleton：贯穿所有层级的最精简切片
TD3: Dependency Problems
TD3：依赖问题
Symptoms: "Blocked on X", diamond dependencies, coordination overhead
Interventions:
- Interface contracts: define API, mock while implementing
- Feature flags: deploy independently, enable when ready
- Branch by abstraction: create layer, swap implementations
症状： “被X阻塞”、菱形依赖、协调开销大
干预措施：
- 接口契约：定义API，实现时使用模拟数据
- 功能开关：独立部署，准备就绪后启用
- 分支抽象：创建抽象层，切换实现方案
TD4: No Clear Done Criteria
TD4：无明确完成标准
Symptoms: "Almost done" forever, no way to verify completion
Interventions:
- Define acceptance criteria (Given/When/Then)
- Time-box to force prioritization
- Define explicit out-of-scope items
症状： 永远“接近完成”，无法验证是否完成
干预措施：
- 定义验收准则（Given/When/Then格式）
- 时间盒强制优先级排序
- 明确定义范围外的项
TD5: Scope Creep
TD5：范围蔓延
Symptoms: Task keeps growing, "while we're here" additions
Interventions:
- Freeze scope, spawn new tasks for additions
- Define minimum viable version
- Ship smallest version that solves the problem
症状： 任务持续膨胀，添加“顺便做”的内容
干预措施：
- 冻结范围，为新增内容创建新任务
- 定义最小可行版本
- 发布能解决问题的最小版本
TD6: Need Spike First
TD6：需要先做Spike
Symptoms: Estimate variance > 4x, new technology, multiple approaches
Interventions:
- Time-boxed spike (8 hours max)
- Deliverables: options, POC, trade-offs, revised estimate
- Spike then implement pattern
症状： 估算差异>4倍、使用新技术、有多种实现方案
干预措施：
- 时间盒限制的spike（最多8小时）
- 交付物：可选方案、POC、权衡分析、修订后的估算
- 先做spike再实现的模式
Decomposition Patterns
分解模式
Vertical Slicing (Preferred for Features)
Vertical Slicing（功能首选）
Feature: User Profile Management
Slice 1: View basic profile (4h)
- UI: Profile display
- API: GET /profile
- DB: Read profile
Slice 2: Edit profile name (6h)
- UI: Edit dialog
- API: PATCH /profile/name
- DB: Update profile
Each slice is independently deployableFeature: User Profile Management
Slice 1: View basic profile (4h)
- UI: Profile display
- API: GET /profile
- DB: Read profile
Slice 2: Edit profile name (6h)
- UI: Edit dialog
- API: PATCH /profile/name
- DB: Update profile
Each slice is independently deployableWalking Skeleton (For New Systems)
Walking Skeleton（针对新系统）
Minimal end-to-end first:
1. Hello World page
2. One GET endpoint
3. Single table
4. Basic deploy
Then flesh out incrementallyMinimal end-to-end first:
1. Hello World page
2. One GET endpoint
3. Single table
4. Basic deploy
Then flesh out incrementallyTracer Bullet (Validate Architecture)
Tracer Bullet（验证架构）
Step 1: Minimal Service A (1h) - Hardcoded response
Step 2: Minimal Service B (1h) - Simple transformation
Step 3: Integrate (2h) - Prove they communicate
Total: 4 hours to decision pointStep 1: Minimal Service A (1h) - Hardcoded response
Step 2: Minimal Service B (1h) - Simple transformation
Step 3: Integrate (2h) - Prove they communicate
Total: 4 hours to decision pointEstimation Techniques
估算技巧
Complexity Sizing (Fibonacci)
复杂度 sizing（斐波那契数列）
| Points | Meaning |
|---|---|
| 1 | Trivial, < 1 hour |
| 2 | Simple, 1-2 hours |
| 3 | Standard, 2-4 hours |
| 5 | Moderate, 4-8 hours |
| 8 | Complex, 1-2 days |
| 13 | Very complex, 2-3 days |
| 21 | Too large, must decompose |
| 点数 | 含义 |
|---|---|
| 1 | trivial，<1小时 |
| 2 | 简单，1-2小时 |
| 3 | 标准，2-4小时 |
| 5 | 中等，4-8小时 |
| 8 | 复杂，1-2天 |
| 13 | 非常复杂，2-3天 |
| 21 | 太大，必须分解 |
Three-Point Estimation
三点估算
O = Optimistic (everything perfect)
L = Likely (normal case)
P = Pessimistic (major issues)
PERT estimate: (O + 4L + P) / 6O = Optimistic（一切顺利）
L = Likely（正常情况）
P = Pessimistic（出现重大问题）
PERT估算公式：(O + 4L + P) / 6Anti-Patterns
反模式
Big Bang Delivery
大爆炸交付
Building complete system before any delivery.
Fix: Vertical slices, incremental value.
在交付前构建完整系统。
修复方案： 垂直切片，增量交付价值。
Technical Tasks Without Value
无业务价值的技术任务
"Set up database," "Create service layer."
Fix: Include in feature tasks: "User can view products (includes DB)."
“搭建数据库”、“创建服务层”。
修复方案： 将其纳入功能任务：“用户可查看产品（包含数据库搭建）”。
Research Forever
无限期研究
Unbounded investigation.
Fix: Time-boxed spikes with deliverables.
无边界的调查。
修复方案： 带交付物的时间盒限制spike。
Perfect Decomposition
完美分解
Over-analyzing before starting.
Fix: Decompose next 2 weeks. Details for later work emerge.
在开始前过度分析。
修复方案： 只分解未来2周的任务。后续工作的细节会逐渐浮现。
Decomposition Checklist
分解检查清单
Before starting any task:
- Can hold all requirements in working memory?
- Duration under 2-3 days?
- Clear acceptance criteria exist?
- Dependencies identified and broken where possible?
- Can be completed independently?
- Delivers verifiable value?
- Estimate confidence is high?
If any "no" → further decomposition needed.
开始任何任务前：
- 能否在工作记忆中记住所有需求？
- 时长是否在2-3天以内？
- 是否有明确的验收准则？
- 是否已识别依赖关系并尽可能拆分？
- 能否独立完成？
- 能否交付可验证的价值？
- 估算的置信度是否高？
如果有任何一项为“否” → 需要进一步分解。
Related Skills
相关技能
- github-agile - Track decomposed work as issues
- system-design - Understand architectural boundaries
- requirements-analysis - Clarify unclear requirements
- code-review - Review after implementation
- github-agile - 将分解后的工作作为问题进行跟踪
- system-design - 理解架构边界
- requirements-analysis - 澄清不明确的需求
- code-review - 实现后进行评审