task-splitting

任务拆分

将源文档转化为明确的任务边界。将拆分与创建分开：先起草并验证，只有在用户明确批准后，才创建 agent-team 任务。

工作流

1. 接收源文档。
2. 提取目标、约束、交付物、非目标和模糊之处。
3. 判断是否需要使用 brainstorming。
4. 按功能边界起草任务。
5. 验证每个任务边界。
6. 每个任务编写一个任务文件。
7. 请求确认。
8. 根据已批准的文件创建 agent-team 任务包。

1. 接收源文档

• 接受原始文档内容或本地文档路径。
• 只读取拆分任务所需的文件。
• 如果文档缺少目标、交付物或任务文件的输出位置，请先询问，再起草。
• 如果用户未指定任务文件的存放位置，请询问一次。如果用户不介意，则将文件放在源文档旁边的同级目录中，目录名为 <document-stem>-tasks/。
• 仅以源文档和用户的澄清内容作为任务范围的依据。

2. 判断是否使用 brainstorming

出现以下任一情况时，应在起草任务前调用 brainstorming：

• 文档目标不明确
• 存在范围冲突
• 有多种同样合理的拆分策略
• 多个功能纠缠在一起
• 用户希望先讨论再起草任务

对于目标明确、边界清晰的文档，不要强行使用 brainstorming。

3. 按功能边界拆分

严格遵循以下规则：

• 每个任务优先对应一个用户可见功能或一个明确的子功能。
• 每个任务只能有一个主要职责。
• 明确划定任务边界。
• 优先每个任务对应一个功能，而不是一段内容。
• 如果按文档章节分组会导致范围混杂，则不要采用这种方式。
• 不要仅仅因为文档将多个功能放在一起描述，就将它们合并。

出现以下任一情况时，应拆分任务：

• 一个任务包含多个并列功能
• 一个任务包含多个验收目标
• 一个任务混合了构建与验证职责
• 任务的依赖链使独立执行变得不明确

4. 验证每个任务边界

有效任务必须包含以下全部内容：

• 仅包含一个功能或子功能
• 仅有一个主要职责
• 明确的完成条件
• 明确的范围内部分
• 明确的范围外部分
• 明确的验收标准
• 可管理的依赖项

如果任务未通过任何一项检查，应在编写文件前拆分或重写。

5. 每个任务编写一个任务文件

• 一个任务必须对应一个任务定义文件。
• 将任务文件视为权威的边界定义。
• 文件名应保持稳定且便于审查，例如 01-auth-login.md、02-auth-session-check.md。
• 使用 references/task-file-template.md 中的模板。
• 不要用合并后的摘要文件代替各个任务文件。

6. 创建前请求确认

• 将起草好的任务集提交审查。
• 明确指出模糊之处和未解决的问题。
• 在创建任何 agent-team 任务前，请求用户明确确认。
• 如果用户要求修改，应先更新任务文件。不要在创建阶段重新定义范围。

7. 根据已批准的文件创建 agent-team 任务

当项目提供 agent-team CLI 时，根据每个已批准的任务文件创建一个任务包。

已确认的命令接口：

agent-team task create --role <role> "<title>" --design "<task-file>"

规则：

• 未经批准，不要创建任务。
• 按任务文件准确保留标题、范围、依赖项和验收标准。
• 创建过程中不要重新解释或扩大范围。
• --role 为必填项。使用文档或任务文件中指定的角色；否则应询问用户，不要猜测。
• 准确报告成功和失败结果。
• 如果创建部分失败，应立即停止，并明确列出已创建的任务和失败项。

输出约定

草稿阶段输出

返回：

• 对拆解内容的简短总结
• 草拟的任务标题列表
• 每个任务文件的文件路径
• 尚未解决的边界问题
• 明确的审批请求

创建阶段输出

返回：

• 每个已创建的任务标题
• 其源任务文件
• 如果有，已创建任务的标识符
• 任何失败及失败文件的确切路径

防护措施

• 不要实现代码更改。
• 不要让创建阶段改写范围。
• 不要将分析、实现和测试合并为一个任务。
• 边界已经明确时，不要强制使用 brainstorming。