任务分解
将设计转化为每个 1 故事点的待办工单，团队中的任何工程师都可以独立捡起、完成并自行合并。
输入
$ARGUMENTS
- 如果提供了路径，则读取该文档。
- 否则，使用此对话或磁盘上最近的 RFC 或来自高效思考会话的
*.notes.md文件。这些通常是本地的、未跟踪的文件（查找在 git 忽略的文件夹中，如.rfcs/，然后是docs/rfcs/、docs/adr/、rfcs/）。如果没有找到，询问要拆解哪个文档或设计。 - 如果源文档存在空白导致无法拆分（未选定的设计、没有发布方案），先列出它们并询问，不要自行编造答案。小的空白可以转化为 Spike 工单。
此处“1 故事点”的含义
当所有以下条件都满足时，工单计为 1 点。如果有一个不满足，则拆分为多个：
- 一个人，大约一天或更少，包括测试和审查修复。
- 一个可审查的 Pull Request，具有单一目的。审查者无需阅读其他打开的 PR 就能理解它。
- 可独立合并。 合并后主分支保持绿色并可发布，这通常意味着新行为位于某个功能标志后面，或者尚未连接起来。
- 可测试。 包含 1-5 条验收标准，且这些标准可以让非作者的人来检查。
- 没有隐藏的未知项。 如果实现者必须先做调研才知道怎么做，那这是一个 Spike，而不是故事。
如果团队有自己的点数定义，遵循他们的定义并在输出顶部注明。
如何拆分
在拆分之前先阅读代码：确认每个工单涉及的文件、模块、schema 和测试确实存在，并在工单中明确命名它们。引用真实路径的工单更容易被捡起；模糊的工单会一直留在待办事项中。
从一个步行骨架开始：最薄的端到端切片，证明设计在产品中有效（通常在功能标志后面），然后逐步加厚。这会将风险前置，而不是在最后一个工单中发现集成问题。
当一个工单太大时，以下拆分方法通常有效：
- 准备，然后变更。 先提出纯粹的代码重构（“让变更变得容易，然后进行容易的变更”），在重构之前用测试固定当前行为。
- 扩展 / 迁移 / 收缩 用于 schema 和 API 变更：新增列或端点，回填或双写，切换读取，然后移除旧路径。每个阶段是一个独立的工单。
- 按功能标志后的层级分层：数据模型 → 服务逻辑 → API → UI，每个都可合并因为标志是关的。
- 读路径优先于写路径，快乐路径优先于边缘情况和错误处理。
- 按变体：在第一个工单建立模式后，每个提供者、文件类型或客户端一个工单。
- 为未知项创建 Spike：有时间限制（≤ 1 天），输出是决策和后续的工单，而不是生产代码。每个 Spike 要有一个可以回答的
Question:和一个时间盒。依赖于该决策的工单仅拆分到安全为止，并注明待 Spike 决策完成后再优化。尽早放置 Spike：它们会阻塞之后的所有内容。
不要忘记那些非功能代码的工作：功能标志的搭建和移除、监控指标/告警/仪表盘、操作手册或文档更新、数据回填、分阶段发布步骤以及旧路径的清理。这些通常是“几乎完成”项目停滞不前的原因。
不要为了拆分而拆分：一个只有与另一个工单合并在一起才有意义的工单应该合并为一个工单，或者这对工单应该沿着不同的切面重新划分。
输出
- 使用 templates/tasks.md 模板编写待办事项，保存为源 RFC 旁边的
<rfc-name>.tasks.md。与 RFC 一样，它是本地工作文件，默认未跟踪；如果其文件夹尚未被 .gitignore 忽略，则将其添加到.git/info/exclude。工单编号为T-01、T-02……以便依赖项可以引用它们，所有状态设置为open，并填写用于分支名称的项目 slug。保持字段名称与模板完全一致，因为/implement-task和/deliver-project会读取它们。 - 将工单分组到与 RFC 阶段对应的里程碑中，每个里程碑以可演示或可发布的内容结束。
- 包含依赖关系图：哪些工单可以并行进行，以及关键路径。当工单数量超过约 8 个时，使用简短的 Mermaid 图效果不错。
- 在聊天中，给出简短摘要：每个里程碑的工单数量、可以立即开始的工单数量、关键路径、Spike，以及任何您不确定是否真的是 1 点的工单。请用户标记看起来太大、太小或顺序错误的工单，并进行修改。
- 发布到团队的跟踪系统。 假设团队使用一个（Linear、Jira、GitHub Issues……）。一旦用户对拆解结果满意，主动提供通过已连接的跟踪工具进行发布；如果没有连接，则说明需要哪个连接器，并提供带有列
ID, Title, Description, Acceptance Criteria, Story Points, Milestone, Depends On, Labels的 CSV 作为备用方案。仅在用户确认后才发布，因为它对团队可见。对于每个工单，创建一个 Issue，包含标题、可独立阅读的描述（上下文、范围、文件、不在范围内的内容、验收标准）、估计为 1、里程碑，以及在跟踪系统支持的情况下的 blocked-by 依赖关系。然后将每个 Issue 的键和链接写入本地文件工单的Tracker:字段中。 - 指向下一步：对于单个工单执行
/implement-task <ticket-id>，对于 Spike 执行/spike-task <ticket-id>，或者使用代理团队运行整个待办事项执行/deliver-project <tasks-file>。
如果源 RFC 有计划执行部分，则更新它以链接到任务文件，而不是重复列表。
在 Spike 之后进行优化
当收到已决策的 Spike 的决策记录（状态为 decided）时，更新待办事项而不是从头开始：
- 应用记录中批准的待办事项变更：添加工单（继续使用
T-NN编号，永不重复使用 ID），修改受影响工单的范围、标准或依赖关系，并将已移除的工单标记为canceled并注明原因，而不是删除它们。 - 重新检查每个变更或新增的工单是否符合 1 点的标准，并更新摘要、依赖关系图和关键路径。
- 更新记录中列出的 RFC 章节。
- 同步跟踪系统：创建新的 Issue，更新已变更的 Issue，取消已移除的 Issue，并将新键写入任务文件。如果用户一次性批准了决策及其待办事项变更，则此批准涵盖了此同步；否则先确认。
- 将 Spike 设置为
done，并用几行文字总结发生了什么变化。