task-decomposer

任务分解器

将模糊的功能需求转化为具体、可实施的任务序列： 确定验收标准，将功能拆解为带工作量估算的垂直切片，梳理依赖关系和并行化机会， 列举边缘情况，规划测试，标注 HITL/AFK 就绪状态，并指出风险，最终产出可立即执行的任务看板。

何时使用此技能而非原生分解： 基础模型擅长以临时格式分解功能。只有在需要结构化输出时，才使用此技能： 包含依赖关系映射、并行化标记、风险标记和集成测试策略的分阶段任务表。如果只需要快速列出步骤，直接提问即可，无需调用此技能。

参考文件

文件	内容	加载时机
references/decomposition-patterns.md	功能 → 任务分解策略、粒度指南	始终
references/edge-case-checklist.md	按领域分类的常见边缘情况（Web、API、数据、CLI）	需要识别边缘情况时
references/dependency-mapping.md	依赖关系图构建、关键路径识别	多任务拆解时
references/sizing-guide.md	工作量估算指南（S/M/L）、复杂度指标	需要估算工作量时

前提条件

• 功能描述或需求（可以模糊——此技能会处理不明确之处）
• 项目背景（技术栈、现有架构、团队规模）

项目背景

分解任务前，检查仓库本地的 Agent 上下文：

• docs/agents/domain.md，了解 CONTEXT.md、CONTEXT-MAP.md 以及 ADR 查找规则
• docs/agents/triage-labels.md，了解任务转为 issue 时使用的就绪标签
• CONTEXT.md 或相关的上下文专属术语表，用于任务标题和验收标准
• .out-of-scope/，查看可能影响范围的长期有效驳回项

如果这些文件不存在，仍可继续，但需说明计划使用的是推断出的术语。

工作流

阶段 1：了解功能

1. 提取面向用户的目标——此功能能让用户做什么？ 如果不明确，请明确说明假设。
2. 定义验收标准——此功能要满足什么条件才算“完成”？ 将其表述为可测试的陈述：“用户可以执行 X”“系统在 Z 时会执行 Y”。
3. 识别非功能性需求——性能、安全性、无障碍性、 向后兼容性约束。
4. 明确范围边界——哪些内容明确不在范围内？说明这一点，以 防止实施过程中范围蔓延。

阶段 2：拆分为垂直切片

先将功能拆分为示踪子弹式切片，再将过大的切片细分为任务。 每个切片都应贯穿受影响的各层，交付一条范围明确但完整的路径。避免 横向拆分：例如，除非工作纯属基础设施，否则不要让一个问题只创建架构，另一个只创建 API，还有一个只创建 UI。

粒度	大小	示例
过粗	“构建搜索功能”	不可执行
合适	“精确匹配的产品搜索端到端返回结果”	单个 PR，可测试
过细	“导入搜索库”	无法独立体现价值

合适粒度检验： 每项任务都应能在单个 PR 中完成、独立测试，并独立交付。完成的垂直切片应可演示 或验证，无需等待无关切片。

将任务分组到不同阶段：

阶段	目的	包含内容
准备	为切片提供共享契约或迁移，以解除阻塞	类型、架构、测试夹具
切片 1	首个端到端行为	最少的数据、逻辑、API、UI/CLI 路径
切片 N	增量能力	一项用户可见行为或运维能力
加固	跨切片的边缘情况和质量门禁	性能、安全、文档、清理

为每个切片标注：

• AFK — Agent 可根据问题简述实现，无需额外的人类上下文。
• HITL — 需要人类判断、外部访问、产品批准、设计评审或发布权限。

阶段 3：识别边缘情况

为每项任务列举边缘情况：

1. 输入边界 — 空值、null、最大尺寸、特殊字符
2. 状态转换 — 并发修改、中断的操作
3. 错误情况 — 网络故障、无效数据、权限被拒绝
4. 向后兼容性 — 现有数据、现有 API 使用方

阶段 4：规划测试

为每项任务确定测试内容：

测试级别	测试内容	编写者
单元测试	单个函数、纯逻辑	实现期间
集成测试	组件交互、API 端点	集成阶段之后
手动测试	用户流程、视觉正确性	润色阶段之后

阶段 5：梳理依赖关系

确定哪些任务依赖其他任务：

1. 硬依赖 — 任务 B 需要任务 A 的产出（必须先有数据库表，才能编写查询）
2. 软依赖 — 任务 B 能从任务 A 中受益，但也可以使用桩
3. 无依赖 — 任务可以并行完成

阶段 6：标记风险

为每项风险确定缓解措施：

风险类型	示例	缓解措施
技术未知	“从未使用过 WebSockets”	先进行技术验证/原型开发
外部依赖	“需要我们目前没有的 API 访问权限”	尽早申请，使用模拟对象
范围不确定	“需求可能会变化”	先实现核心功能，推迟处理边缘情况
性能风险	“处理 100 万行时可能会很慢”	添加基准测试任务，定义可接受的阈值

输出格式

## Task Decomposition: {Feature Name}

### Feature Summary
{One paragraph describing what this feature does and why}

### Acceptance Criteria
- [ ] {Testable statement 1}
- [ ] {Testable statement 2}
- [ ] {Testable statement 3}

### Scope
- **In scope:** {what's included}
- **Out of scope:** {what's excluded}

### Task Breakdown

#### Phase 1: Foundation
| # | Slice / Task | Type | Effort | Dependencies | Parallel |
|---|--------------|------|--------|--------------|----------|
| 1.1 | {task description} | {AFK/HITL} | {S/M/L} | None | Yes |
| 1.2 | {task description} | {AFK/HITL} | {S/M/L} | 1.1 | No |

#### Phase 2: Vertical Slices
| # | Slice / Task | Type | Effort | Dependencies | Parallel |
|---|--------------|------|--------|--------------|----------|
| 2.1 | {end-to-end behavior} | {AFK/HITL} | {S/M/L} | 1.x | Yes |
| 2.2 | {end-to-end behavior} | {AFK/HITL} | {S/M/L} | 1.x | Yes |

#### Phase 3: Hardening
| # | Task | Type | Effort | Dependencies | Parallel |
|---|------|------|--------|--------------|----------|
| 3.1 | {cross-slice quality gate} | {AFK/HITL} | {S/M/L} | 2.x | No |

### Edge Cases

| # | Edge Case | Handling | Phase |
|---|-----------|----------|-------|
| 1 | {edge case} | {how to handle} | {which phase} |

### Test Strategy

#### Unit Tests
- {Component}: {what to test}

#### Integration Tests
- {Flow}: {what to test}

#### Manual Verification
- {Scenario}: {what to check}

### Risk Flags
- {Risk}: {mitigation strategy}

### Agent Brief Notes
- {Any interface contracts, acceptance criteria, or out-of-scope boundaries that should be copied into ready-for-agent issues}

校准规则

1. 粒度要恰当。 每个切片应包含 1-3 天的工作量，每项实现任务都应能在一个 PR 中完成。规模更大 → 进一步拆分。规模更小 → 合并到上级切片。
2. 验收标准必须可测试。 “让搜索能用”不可测试。“对于长度不超过 100 个字符的查询，搜索能在 200ms 内返回相关结果”则可测试。
3. 依赖关系至关重要。 如果任务 B 确实依赖任务 A，请标明。错误的依赖关系会拖慢团队进度；遗漏依赖关系会导致集成失败。
4. 边界情况不可忽略。 每项功能都有边界情况。如果边界情况列表为空，说明分析尚不完整。
5. 并行意味着更快。 尽可能增加并行任务。如果 4 项任务可以同时进行，阶段所需时间取决于其中耗时最长的一项，而不是总和。
6. 优先纵向拆分。 优先选择端到端切片，而非仅针对某一层的任务。只有在共享契约、迁移或基础设施确实能解除切片阻塞时，才采用横向任务。
7. 交给 Agent 前必须准备好简报。 AFK 切片需要明确期望行为、关键接口、验收标准和范围外边界，确保新的 Agent 能据此开展工作。

错误处理

问题	解决方案
功能描述含糊	陈述假设，拆分已知内容，并将不确定的任务标记为“待澄清”。
功能规模过大（20 项以上任务）	拆分为多个功能。需要数月才能完成的功能属于项目，而非功能。
验收标准不明确	帮助用户定义：“怎样才算完成？你会演示什么？”
技术栈未知	按逻辑层面拆分（数据模型、业务逻辑、API、UI），不涉及具体实现细节。

不要拆分的情况

以下情况应提出异议：

• 任务已经是原子性的（单个函数、单个文件变更）——直接完成即可
• 用户需要的是时间估算，而非任务拆分——改用 estimate-calibrator
• 功能属于探索性质（研究、原型）——拆分的前提是范围已知
• 目标或定义目标所需的决策仍未知——改用 decision-map