# Task Decomp

> 任务拆分 — 功能到任务的分解，确保粒度单一可控。当 ARCH 完成、需要拆解任务卡、划分 Sprint 或定义 TDD 验收标准时使用。

- Skill: `lync-cyber/task-decomp` (Agent Skill)
- Install (CLI): `npx skillmds@latest add lync-cyber/task-decomp`
- Raw SKILL.md: https://api.skillmd.com/api/skills/lync-cyber/task-decomp/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: lync-cyber (https://skillmd.com/u/lync-cyber)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/lync-cyber/task-decomp

---


# 任务拆分 (task-decomp)
## 能力边界
- 能做: 功能→任务分解、复杂度评级、Sprint 初步划分、TDD 验收标准定义
- 不做: 架构决策、代码实现、测试执行、最终 Sprint 分组判定（依赖关系由 task-dep-analysis 计算并给出权威建议）

## 输入规范
- ARCH模块划分(M-{NNN}) + 接口契约(API-{NNN})
- UI-SPEC组件(UC-{NNN}) + 页面(P-{NNN})

## 输出规范
- 任务卡(T-{NNN})，每个包含:
  - 目标、模块、接口、复杂度(S/M/L/XL)
  - tdd_acceptance: 验收标准映射（GWT 格式，见执行流程 3）
  - deliverables: 交付物文件清单
  - context_load: context加载清单
  - 实现提示(仅在必要时)
- Sprint划分表
- 依赖图 + 关键路径
- 集成/E2E测试规划: 按Sprint标注需验证的模块间交互和端到端用户流程

## 执行流程
1. 从ARCH模块和接口推导任务
2. 评估每个任务复杂度：跨越多个模块、或 context_load > 5 个章节、或步骤无法在单次 Agent 调用中枚举完整时，继续拆分
3. 定义tdd_acceptance(映射AC)。每条 AC 采用 Given-When-Then 格式：
   - Given: 前置条件（输入数据、系统状态）
   - When: 触发动作（调用方法、发送请求、用户操作）
   - Then: 可观测结果（具体返回值/字段、状态变化、错误类型+消息）
   - Then 子句必须包含可断言的具体值或约束，禁止"实现 X"、"支持 Y"等无行为描述
   - 契约完整性对账: AC 引用某 `arch#§N.API-xxx` 契约时，把契约声明的全部响应码 / 安全路径 / 集成点逐一与派生 AC 交叉核验；每项须有对应 AC，无对应的须显式标 `[ASSUMPTION]` 豁免并附理由
4. 定义deliverables(明确交付文件)
5. 定义context_load(context引用)
6. 建立依赖图: 调用 task-dep-analysis skill 计算拓扑/关键路径/环检测，再用 `cataforge viz tasks --format mermaid` 产出 Mermaid 依赖图并写入 dev-plan#§2
7. 按依赖关系划分Sprint(参考 task-dep-analysis 输出的 sprint_groups)，遵循 Sprint 切分原则:
   - 每个 Sprint 的产出应包含至少一个用户可感知的完整功能
   - 优先安排用户核心路径（`user_facing_critical_path: true`）的任务到前几个 Sprint
   - Sprint 1 例外: 基础设施任务允许集中在首个 Sprint，不要求用户可感知功能
   - 纯后端服务项目无此约束
   - arch §1.5 external_oracles 非空时，Sprint 1 强制一张 `walking_skeleton: true` 任务卡并作为规模化 Sprint 的 blocking dependency（契约见 [`external-truth-first.md`](../../references/external-truth-first.md)；doc-review Layer 1 强制）
8. 插入验证任务: 每个包含 `user_facing_critical_path: true` 任务的 Sprint 末尾，追加一个 `task_kind: validation` 的验证任务。验证任务不产出代码，orchestrator 遇到时暂停并向用户展示验证清单

## Anti-Patterns
- 禁止: 单任务预估 LOC > `TASK_SPLIT_LOC` 或 AC > 6 条而不拆 —— 超此尺寸任务粒度不再单一，应在 task-decomp 阶段先拆
- 禁止: 把"重构 X"作为独立任务 —— 重构是 TDD REFACTOR 阶段的自然产物，独立 T-xxx 会让重构脱离测试安全网
- 禁止: deliverables 仅写 "实现 X 功能" 而不具体到文件路径 —— sprint-review 无法验证 AC 是否落到声明文件，验收形同虚设
- 避免: 任务横跨 ≥3 个 `arch#§2.M-xxx` —— 跨模块任务在 task-dep-analysis 输出中容易触发环依赖
- 禁止: AC 仅描述"实现 X 功能"/"支持 Y 格式" —— 模糊 AC 导致 test-writer 退化为存在性检查，无法推导断言期望值
- 禁止: AC 只覆盖被引用 `arch#§N.API-xxx` 契约的正常路径 —— 如契约声明 `401 E_AUTH` + `403 E_PERMISSION_DENIED` 两条安全路径，AC 只测正常返回，缺口要到下游 code-review 标 HIGH 或 pre-wiring 审计才暴露
- 禁止: arch 模块为有序管线（stage 序列）时遗漏某 stage 的承载任务 —— 模块管线含 A→B→C 三 stage 而只为 A、C 建任务卡，B 接线无任务、以空返回满足下游字面 AC，运行时管线在 B 静默断裂；每个 stage 的接线须有任务卡 deliverables 承载
- 禁止: Sprint 内全部为后端任务而无任何用户可感知的功能交付（Sprint 1 例外），除非项目为纯后端服务
- 禁止: task-dep-analysis 报环依赖或无法计算拓扑序时仍输出任务计划 —— 环路使 Sprint 排期失真，应返回 blocked 附环路 task_id 链请人工拆环（COMMON-RULES §通用 Error Handling），不静默降级为无序计划

## 效率策略
- 先拆后排: 先拆任务再排依赖
- context_load精确到章节，避免全文加载