lanrtop 731fa11456 feat(onboarding+skill): B3 acceptance 可执行化 + template v1.2.0 + skill 升级

- AGENTS.md.tmpl: v1.2.0，新增 rule#5 acceptance 可执行化（[载体] 调用→断言）
- 炼境 AGENTS.md: ONBOARDING_MANAGED 同步至 v1.2.0
- /architect: 新增 Step 3.5 声明验证路径载体（Tauri/HTTP/CLI/Playwright 优先级表）
- /splitter: acceptance 格式升级为可执行验证路径，含三类示例

2026-07-03 21:12:22 +09:00

2.8 KiB

Raw Blame History

name	description	allowed-tools
splitter	将 architect 的设计文档拆解为任务卡，若项目有 .blueprint/ 则写入蓝图文件。Use after /architect for L-complexity tasks.	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：可执行验证路径，格式：[载体] 调用/运行什么(参数) → 断言什么
- 载体从 architect 的「验证路径」声明继承，就近选择：Tauri command / HTTP API / CLI / Playwright
- 断言要具体（检查字段值、返回码、文件存在、数量 > 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，在末尾追加任务卡：

### 📋 <任务标题>
- 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/ 时）

## 任务拆解：<功能名>

### 📋 <卡名>（S）
- files: ...
- acceptance: "[载体] 调用什么(参数) → 断言什么"

### 📋 <卡名>（M）
- files: ...
- acceptance: "[载体] 调用什么(参数) → 断言什么"
- depends: 上一张卡

4. 输出拆解摘要

共 N 张任务卡，执行顺序：
1. 📋 <卡名>（S）— <一句话说明>
2. 📋 <卡名>（M）— <一句话说明>
3. 📋 <卡名>（M）— <一句话说明，depends: 卡2>

质量检查

写完后逐张确认：

每张卡有 files
每张卡有 acceptance
complexity 全部是 S 或 M
有依赖的卡填了 depends
任务卡按执行顺序排列

2.8 KiB Raw Blame History Unescape Escape