--- name: splitter description: 将 architect 的设计文档拆解为任务卡,若项目有 .blueprint/ 则写入蓝图文件。Use after /architect for L-complexity tasks. allowed-tools: Read, Edit, Write, Glob --- # 任务拆解 将架构设计拆解为可独立执行的任务卡。 ## 前提 当前对话中应已有 `/architect` 输出的设计文档,包含受影响文件和拆解建议。 ## 步骤 ### 1. 确认任务管理方式 - 若项目存在 `.blueprint/manifest.yaml` → 写入蓝图文件 - 若不存在 → 以 Markdown 列表输出到对话,由用户决定放哪里 ### 2. 拆解原则 **粒度控制** - 每张卡 complexity 必须是 `S` 或 `M`,不允许 L - S:单文件改动,逻辑简单,独立可完成 - M:跨 2-3 个文件,有业务逻辑,但边界清晰 - 拆出来还是 L → 继续细拆 **依赖顺序** - 数据层(schema / model)→ 后端接口 → 前端封装 → UI 组件 - 有依赖的卡填写 `depends` 字段 **可派发标准(每张卡必须满足)** - `files`:明确列出涉及文件的相对路径 - `acceptance`:一句话验收标准,描述可观察的结果 - `complexity`:S 或 M ### 3a. 写入蓝图(有 .blueprint/ 时) 读取 `.blueprint/modules/.md`,在末尾追加任务卡: ```markdown ### 📋 <任务标题> - status: todo - complexity: S|M - files: src/path/to/file.tsx, src-tauri/src/commands/xxx.rs - depends: <依赖模块id>(可选) - acceptance: <一句话验收标准> ``` 然后更新 `manifest.yaml`:status → `planned`,`updated` 改为今天日期。 ### 3b. 输出到对话(无 .blueprint/ 时) ```markdown ## 任务拆解:<功能名> ### 📋 <卡名>(S) - files: ... - acceptance: ... ### 📋 <卡名>(M) - files: ... - acceptance: ... - depends: 上一张卡 ``` ### 4. 输出拆解摘要 ``` 共 N 张任务卡,执行顺序: 1. 📋 <卡名>(S)— <一句话说明> 2. 📋 <卡名>(M)— <一句话说明> 3. 📋 <卡名>(M)— <一句话说明,depends: 卡2> ``` ## 质量检查 写完后逐张确认: - [ ] 每张卡有 `files` - [ ] 每张卡有 `acceptance` - [ ] complexity 全部是 S 或 M - [ ] 有依赖的卡填了 `depends` - [ ] 任务卡按执行顺序排列