用途
Task Splitting 用于把需求、设计或头脑风暴类源文档，转化为边界明确、可评审的任务草稿。它的核心原则是把“拆解”和“创建”分开：先起草并验证任务边界，只有在用户明确批准之后，才创建 agent-team 任务。
主要能力
- 接收原始文档内容或本地文档路径，只读取拆解所需的文件。
- 从文档中提取目标、约束、交付物、非目标以及歧义点。
- 判断是否需要先进行头脑风暴。
- 按功能边界起草任务，而不是按文档段落或章节划分。
- 对每个任务边界进行校验，确保其满足有效性要求。
- 为每个任务编写一个任务文件，作为该任务边界的权威定义。
- 在创建任务前请求用户确认。
- 从已批准的任务文件创建 agent-team 任务包。
使用方式
工作流分为七个步骤：
-
接收源文档：接受原始文档内容或本地文档路径。如果文档缺少目标、交付物或任务文件的目标输出位置，需要先询问。如果用户未指定任务文件存放位置，询问一次；若用户不在意，则放在源文档同级的
<document-stem>-tasks/目录下。源文档加上用户澄清是任务范围的唯一依据。 -
判断是否使用头脑风暴：当文档目标模糊、存在范围冲突、多种拆解策略同样合理、多个功能纠缠在一起，或用户希望在起草任务前先讨论时，先调用头脑风暴。对于清晰、边界明确的文档，不强制使用头脑风暴。
-
按功能边界拆解：严格遵循规则——每个任务优先对应一个用户可见功能或一个清晰的子功能；每个任务只保留一个主要职责；任务边界必须明确；优先“一个功能一个任务”，而不是“一个段落一个任务”；当按文档章节分组会造成范围混杂时，拒绝这种分组；不要因为文档把多个功能放在一起叙述就合并它们。当任务包含多个同级功能、多个验收目标、混合构建与验证职责，或依赖链导致独立执行不清晰时，应拆分任务。
-
校验每个任务边界：有效任务必须包含——恰好一个功能或子功能、恰好一个主要职责、清晰的完成条件、明确的范围内部分、明确的超出范围部分、明确的验收标准、可管理的依赖关系。如果任务未通过任何检查，先拆分或重写，再写文件。
-
每个任务写一个任务文件：一个任务必须对应一个任务定义文件。任务文件是该任务边界的权威定义。命名保持稳定且可评审，例如
01-auth-login.md、02-auth-session-check.md。使用references/task-file-template.md中的模板。不要用合并的摘要文件代替逐任务文件。 -
创建前请求确认：展示起草的任务集供评审，暴露歧义和未解决问题，在创建任何 agent-team 任务前请求明确确认。如果用户要求修改，先更新任务文件，不要在创建阶段重新定义范围。
-
从已批准文件创建 agent-team 任务：当项目暴露 agent-team CLI 时，为每个已批准的任务文件创建一个任务包。已确认的命令形式为：
agent-team task create --role <role> "<title>" --design "<task-file>"
规则：未批准前不创建任务；严格保留任务文件中的标题、范围、依赖和验收标准；创建期间不重新解释或扩展范围；--role 为必填，使用文档或任务文件中指定的角色，否则询问用户而不是猜测；报告确切的成功和失败结果；如果创建部分失败，停止并明确返回已创建的任务和失败项。
输出约定
起草阶段输出：拆解简短摘要、起草的任务标题列表、每个任务文件的路径、任何未解决的边界问题、明确的批准请求。
创建阶段输出：每个已创建任务的标题、其源任务文件、已创建的任务标识符（如可用）、任何失败及其确切失败文件。
适用场景
- 需要把需求、设计或头脑风暴文档转化为可执行任务清单的团队。
- 希望任务边界清晰、职责单一、便于评审和独立执行的场景。
- 使用 agent-team 工作流，需要从文档生成任务包的项目。
限制
- 不实现代码变更。
- 创建阶段不得重写范围。
- 不得把分析、实现和测试合并到一个任务中。
- 边界已经清晰时，不强制使用头脑风暴。
- 关于收费、价格、平台支持等具体信息，资料中暂未提供。