05d7673990
T2 git-workflow 模板升 v1.3.0: - 分支策略从强制 dev→main 改为复杂度感知 （简单改动直推 main/master，功能性改动开 feat/<name> 分支+PR） - PR 创建 MCP 示例 head 从 "dev" 改为 "feat/<name>" B3 agent 按钮载体声明闭环: - CONVENTIONS.md manifest.yaml 规范新增 agent_button_carrier 字段 （tauri/http/cli/playwright，新建蓝图时必填） - splitter SKILL.md 三级优先载体继承：manifest字段 > architect声明 > 就近推断 - 炼境自身 manifest.yaml 补 agent_button_carrier: tauri - AGENTS.md.tmpl 项目概况 TODO 提示新增载体字段填写指引 Rules-Applied: R04,R13
91 lines
3.1 KiB
Markdown
91 lines
3.1 KiB
Markdown
---
|
||
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`：**可执行验证路径**，格式：`[载体] 调用/运行什么(参数) → 断言什么`
|
||
- **载体来源（优先级）**：
|
||
1. 先读 `.blueprint/manifest.yaml` 的 `agent_button_carrier` 字段
|
||
2. 无此字段时，从当前对话中 `/architect` 的「验证路径」声明继承
|
||
3. 两者都没有时，就近推断：Tauri 桌面应用 → `cargo test`，Web 服务 → HTTP API，CLI → 命令行
|
||
- 断言要具体（检查字段值、返回码、文件存在、数量 > 0），不写模糊的"功能正常"
|
||
- 示例：`[Tauri command] apply_onboarding_pack(project_id) → 返回 written≥1，磁盘上文件存在`
|
||
- 示例：`[HTTP API] POST /api/projects → 201，body.id 非空`
|
||
- 示例：`[cargo test] cargo test parse_conventional → 6 个 case 全通过`
|
||
- `complexity`：S 或 M
|
||
|
||
### 3a. 写入蓝图（有 .blueprint/ 时）
|
||
|
||
读取 `.blueprint/modules/<id>.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`
|
||
- [ ] 任务卡按执行顺序排列
|