wbs-decomposition

WBS Task Decomposition

Applicable Scenarios

• Break the PRD into execution tasks at project kickoff
• Sprint/Cycle planning
• Break down complex features into subtasks
• Assign work to workflows

Core Principles

分解到可执行粒度（不是越细越好）：
  - AI 工作流：每个任务 5~60 分钟
  - 超过 1 小时的任务继续拆
  - 不到 5 分钟的任务可以合并

Each task must satisfy: □ Has a clearly responsible workflow □ Has verifiable completion criteria □ Duration is estimable □ Deliverable is clear

## 标准 WBS 层级

```text
项目目标
  → 阶段（需求/设计/开发/测试/部署）
    → 工作流（前端/后端/QA/DevOps...）
      → 任务（具体可交付的工作单元）
        → 验收标准

Task List Template

| # | 任务 | 工作流 | 依赖 | 工期 | 状态 | 验收标准 |
|---|------|--------|------|------|------|---------|
| 1 | PRD 评审 | product-manager | - | 15min | done | PRD 已输出，验收标准已定义 |
| 2 | API 契约设计 | api-designer | #1 | 20min | todo | OpenAPI 文档已输出 |
| 3 | 数据库设计 | database-engineer | #1 | 15min | todo | DDL + 迁移脚本就绪 |
| 4 | 后端开发 | backend-engineer | #2, #3 | 45min | todo | 接口可调用，测试通过 |
| 5 | 前端开发 | frontend-engineer | #2 | 45min | todo | 页面可用，联调通过 |
| 6 | 联调 | fullstack-engineer | #4, #5 | 20min | todo | 端到端流程通过 |
| 7 | QA 测试 | qa-engineer | #6 | 30min | todo | 测试报告已输出 |
| 8 | 安全检查 | security-engineer | #4 | 20min | todo | 安全报告已输出 |
| 9 | 部署 | devops-engineer | #7, #8 | 15min | todo | 服务上线，健康检查通过 |
| 10 | 文档 | technical-writer | #9 | 15min | todo | README + API 文档已输出 |

Task JSON Structure (machine-readable)

{
  "project": "用户管理模块",
  "tasks": [
    {
      "id": "T1",
      "name": "PRD 评审",
      "workflow": "product-manager",
      "dependencies": [],
      "estimated_minutes": 15,
      "status": "done",
      "acceptance": "PRD 已输出，验收标准已定义",
      "artifacts": ["docs/prd.md"]
    }
  ]
}

Duration Estimation (AI pace)

简单任务（生成单文档/单文件）：5~15 分钟
中等任务（实现一个接口/一组测试）：15~45 分钟
复杂任务（多文件联动/架构设计）：30~90 分钟
人工节点（审批/确认）：标注"等待"，不计入 AI 工期

瓶颈通常不在 AI 速度，而在：
  - 人工审批/确认
  - 外部依赖
  - 工作流间交接质量

缓冲策略：
  - 联调缓冲：15~30 分钟
  - 返工缓冲：每个里程碑后预留一轮

Workflow

1. 读取 PRD/功能范围
   ↓
2. 识别需要哪些工作流参与
   ↓
3. 按阶段（需求/设计/开发/测试/部署）拆顶层任务
   ↓
4. 每个顶层任务拆到工作流粒度
   ↓
5. 每个工作流任务拆到 5~60 分钟粒度
   ↓
6. 每个任务定义验收标准
   ↓
7. 输出任务清单（含 ID、依赖、工期、负责工作流）
   ↓
8. 转交 critical-path skill 识别关键路径

Quality Self-Check

□ 每个任务是否 ≤ 60 分钟（超过就继续拆）
□ 每个任务是否有明确负责工作流
□ 每个任务是否有可验证完成标准
□ 任务总数是否合理（M 级 5~10 个，L 级 10~20 个，XL 级 20+）
□ 是否标注了人工等待节点
□ 是否覆盖了所有阶段（不漏文档/部署/安全）

Common Pitfalls

1. Too coarse— a "develop backend" task takes 4 hours
2. Too fine— counting "open the IDE" as a task too
3. No acceptance criteria— the definition of task "completion" is vague
4. Forgetting non-development tasks— documentation, testing, deployment, security
5. Counting human waiting time as AI duration— inflated estimates
6. No buffer left— no time reserved for integration and rework

Supporting Templates

• templates/wbs-template.md — Task list Markdown template
• templates/project-plan-template.md — Complete project plan template (including milestones and resources)
• templates/task-json-template.json — Machine-readable JSON template

Collaboration with Other Skills

上游：
  产品经理 PRD / 用户故事

下游：
  critical-path → 识别关键路径
  orchestration → 决定编排模式
  handoff-protocol → 定义交接
  progress-tracking → 追踪状态