task-breakdown

Task Breakdown 的核心目标是把大块工作拆成小而可交付的片段。资料明确指出：如果一个任务超过 3 天，就说明拆得还不够细。

用途

该技能用于把架构与规格转化为可执行的工作项，是“要构建什么”与“如何增量构建”之间的关键桥梁。良好的拆解可以支持并行、降低风险，并提供清晰的进度信号。在具备生命周期意识的系统中，任务拆解必须保留上游边界：不要把未解决的架构问题变成实施承诺，也不要把棕地现代化当作全新重写来拆解。

输入

architecture-doc：必需，提供组件边界、接缝决策与共存约束。
api-contract：可选，但当实施工作包含面向 API 的变更或兼容面时强烈建议提供。
spec-doc：可选，用于规格驱动或瀑布路径的补充输入。

主要能力与流程

识别工作包：从架构中识别主要工作区域，包括后端 API 端点、数据模型与迁移、前端组件与页面、基础设施与部署、集成点与第三方服务。对于棕地工作，围绕可逆接缝、共存适配器、兼容边界以及特征化/回归安全来识别工作包，而不是假设只做替换式实现。
拆解为任务：每个任务应可在 1-3 天内完成（更长则继续拆解）、可独立测试（有明确的“完成”状态）、单一职责（一个任务只关注一件事）。命名模式为 [动词] [名词] [上下文]，例如“实现用户注册 API 端点”“为订单表创建数据库迁移”“为结账表单添加输入验证”。在可能的情况下，拆解为保留用户可见或契约可见价值的垂直切片，而不是仅按层排序。
映射依赖：识别哪些任务必须先于其他任务完成，例如数据模型先于 API、API 先于前端、核心功能先于边缘情况、基础设施先于部署。用有向无环图（DAG）可视化，以识别关键路径与并行机会。标记被未解决上游问题阻塞的任务，不要用乐观排序隐藏这些阻塞。
定义完成标准：每个任务都有明确的“完成”标准，包括代码已编写并自审、测试已编写并通过、文档已更新（如适用）、可供代码评审。
为最优流动排序：排序目标是减少阻塞时间（尽早解决依赖）、支持并行工作（独立任务可同时进行）、增量交付价值（可交付切片而非分层）、在棕地系统中保留回滚与共存安全。

棕地排序启发式

当工作属于现代化或迁移时：优先围绕兼容接缝排序；在风险较高的实施任务之前先落地特征化或契约测试；在任务列表中显式保留旧路径与新路径支持；避免依赖未解决架构问题的公共 API 或数据迁移承诺；在共存重要时，把回滚或回退工作作为一等任务。

输出

task-list：由该技能产出。
dependency-graph：由该技能产出。

质量门禁

每个任务为 1-3 天工作量。
依赖已映射且无循环依赖。
关键路径已识别。
每个任务有清晰完成标准。
任务排序以最大化并行为目标。
棕地任务在适用时保留共存与可逆性约束。

反模式

水平切片：“先构建所有数据库层，再构建所有 API 层，再构建所有 UI。”垂直切片（一个功能端到端）能更快交付价值。
巨型任务：“实现认证”不是一个任务，应拆分为注册、登录、密码重置、会话管理等。
未映射依赖：开发人员因等待其他任务而被阻塞，会造成空闲时间与挫败感。
过度拆解：小于 2 小时的任务会带来额外开销，应找到合适粒度。
把规划当作重写幻想：把共存架构变成只做替换的任务计划，忽略回滚与兼容工作。

技能介绍