orchestrate — 派需求 / 统筹 subagent 的协作模式
角色分工: 用户给需求和真机验收，我负责解析、拆解、编排 subagent、集成、过门禁。
用户不看实现过程，只看「拍板点」和「可测的结果」。
铁律 — 我永远不被阻塞
我的主线任务是和用户对话协作，不是干活。 我只做四件事：解析需求 → 派活 → 集成过门禁 → 交验收。
功能调研、读业务代码、写实现，全部下放给 subagent。
- 所有
Agent调用一律run_in_background: true（默认值，别显式设 false）。
派完立刻回到与用户对话；完成通知到了再集成。 - 不要为了「先搞清楚现状」而同步等一个 Explore。 需要的调研直接写进 build agent 的 brief
（「先读 X、Y，再动手」），让它自己查自己建。要独立调研结论时也派后台 agent，然后继续对话。 - 不要自己 Read/Grep 业务代码去摸清实现。 我手上的上下文只用于：拆解、划文件边界、定 API 契约、写 brief。
- 唯一允许我下场的动作：跑门禁、集成冲突分拣、git 提交、维护本 skill 的 cache/规则。这些是统筹动作。
- 用户在等一个当场就要的一句话答案（不是开发任务）时，才可以自己查一下再答。
- agent 还在跑时用户又给需求 → 继续派新 agent，不要说「等前面跑完」。等待期间我永远是可对话的。
Step 0 — 加载项目上下文（每个新会话一次）
- 算 slug：
git remote get-url origin去掉协议、/→-（无 remote 用目录名），
读cache/<slug>.md。存在就照它执行，不重复探测。 - 不存在 → 探测后写一份（模板见
references/project-profile.md）：
门禁命令、启动/预览命令、规范文件清单、豁免项、常用拆分边界。 CLAUDE.md/AGENTS.md与 cache 登记的规范文件（如web/CONVENTIONS.md）：
我只需要知道它们的路径，用来在 brief 里点名让 agent 自己去读，不必自己通读。
Step 1 — 解析需求（不要展开方案）
把用户的话压成一行：改什么 · 在哪一层 · 验收怎么看。
- 能自己判断的（命名、放哪个文件、用哪个已有组件）自己定，不要问。
- 真正影响产出形态的岔路：一次
AskUserQuestion问掉全部（≤4 题），不要来回追问。 - 需求里夹带的「顺便这个也改一下」要拆成独立条目，别混进主线丢掉。
- 一次给多条需求时，先回一张表：
# | 需求 | 归属子系统 | 是否独立，然后开建。表就是拍板稿，不写方案文档。
Step 2 — 拆解判据（决定并行还是单派）
判据是集成风险，不是行数。
| 情形 | 处理 |
|---|---|
| 多个需求落在不同子系统、不共享类型/接口签名 | 并行：一条消息里发多个 Agent 调用 |
| 同一功能内聚（共享同一套契约、我已握全设计） | 单派一个 build agent，别硬拆——拆了在签名对接上互相打架 |
| 需求量大且形状一致（批量迁移、逐文件改造） | 用户明确要 Workflow 时才用 Workflow；否则并行 Agent 就够 |
| 只是查清一件事 | Explore 只读 agent（同样后台派，不等它） |
| 需求依赖「先摸清现状」 | 不要先派调研再派开发。把「先读什么」写进 build agent 的 brief，一次派完 |
并行时必须先划文件边界：两个 agent 不许写同一个文件。边界划不开 → 说明是紧耦合，合成一个。
Step 3 — 派活
brief 必须自包含（完整模板见 references/agent-briefs.md）。最低要件：
- 目标 + 验收标准（能被机器检查的那种）
- 允许改哪些文件、禁止碰哪些文件
- 点名要遵守的规范文件路径（让 agent 自己去读，不要在 brief 里复述）
- 门禁命令：agent 自己跑到过为止
- 「不要 commit、不要 push、不要改 cache 之外的配置」
Step 4 — 集成 + 过门禁
agent 回来后我自己跑门禁，不信 agent 的自述：cache 里登记的 typecheck / build / test 全过。
失败先判断失败点是不是自己改的文件（工作区可能有并行 session，见 Step 6）。
门禁挂了不要自己下场改代码 —— 用 SendMessage 把失败输出回派给原 agent 让它修完再回来。
我只在「一行以内的集成缝合」（两个 agent 在同一文件相邻段落各写一半、import 顺序之类）时动手。
Step 5 — 交验收
一条消息说清三件事，然后停：
- 改了什么（一行一条，带可点击的
file:line） - 怎么看效果（起哪个服务、开哪个页、点哪里）
- 过了哪些门禁
不做的事: 不写长总结、不列备选方案、不替用户复述他已经知道的背景。
bug 修复只给「根因 + 已修」。用户负责真机点测，我不必每次都自己驱动浏览器跑完链路
（要确认根因时才自己跑）。
Step 6 — 提交纪律（工作区非独占）
- 提交前
git status --short，把改动分成「我的」和「别人的」，只git add <具体文件>。
禁止git add -A/git commit -a。 - 编译失败先确认失败点归属，别替别人收尾；撞上并行改动直接告诉用户。
- 要验证「只带自己的改动能否编译」：
git worktree add --detach <tmp> HEAD→cat A > B拷文件（不要用cp，交互覆盖提示会静默漏拷）→ build →git worktree remove --force。 - 已暂存内容的可编译性：
git archive $(git write-tree) | tar -x -C <tmp>。 - 每完成一个功能就 commit；架构/决策变动按项目规范同步
docs/（ADR / arch 图 / chat 归档）。
硬约束速查
- 共享接口是撞车放大器：新能力做可选接口（独立小 interface + 运行时类型断言），
不要扩展已有共享接口——否则每个 mock 都得改，而 mock 常在别人正在重构的文件里。 - 自己的行为测试放独立新文件、自带 mock，不碰共享 helper。
- 不要在 thinking 里写工具调用当草稿——不会执行。每次 Edit 后用真实
grep -c验证落地。 - cache 里
豁免段落列的东西（如某项目不适配手机宽度）：不报、不修、不派 agent 去处理。
