| name | plan-first |
|---|---|
| description | 议行分离协作机制——任何会产生变更的任务，先出方案、等用户确认后才执行。触发词：「先议后行」「先商量」「方案先行」「议行分离」「先出方案」「plan first」等，或直接 /plan-first。适用：写论文、改文档、改代码、跑实证、参与开源协作等一切非只读任务。 |
plan-first：先议后行
协作铁律：方案未获用户确认，不产生任何持久影响——不改文件、不跑有副作用的命令、不 push、不发布。
进入方式（默认动作）：任何变更任务开始前，先问用户「进不进入 plan-first 议行分离？」——用户说「直接改」「小事」「不进了」则跳过本流程直接执行；否则进入下方流程。用户主动说触发词（「先议后行」「先商量」「方案先行」等）时同样进入；CC/DSH 侧也可输入 /plan-first（ZC 侧 skills 不进 / 菜单，用 $ 或触发词）。
第一步：判定任务级别
| 级别 | 判定 | 流程 |
|---|---|---|
| A 只读 | 查询/检查/诊断/读文件/跑无副作用命令 | 直接做，不需要方案 |
| B 小事 | 一句话可描述、≤2 文件、无结构决策；或用户明确说「直接改」「顺手改」 | 一句话确认：「要改 X，直接改吗？」 |
| C 常规 | 单模块、≤5 文件、有取舍 | 完整方案块 → 确认 → TodoWrite → 执行 |
| D 复杂 | 跨模块/多阶段/跨天 | 完整方案块 → 确认 → TodoWrite + 阶段确认点 |
拿不准级别时按更高一级处理。
第二步：输出方案块（C/D 类）
严格按此格式，输出在对话里，不写文件：
## 方案
- 目标：做什么、解决什么
- 方案选项与取舍：2-3 个可行方案 + 各自取舍 + 推荐（先想「怎么做会搞砸」，列出要避开的坑）
- 影响范围：改哪些文件、跑哪些命令、是否触及红线（删除文件 / git push / 改密钥 / 装全局依赖 / 对外发布）
- 验证方式：怎么确认做对了（测试 / 复算 / 目视 / 命令）
- 待确认点：需要用户拍板的问题
（看到此处 = 方案未确认，不得执行）
第三步：等确认
- 确认词：执行 / OK / 动手 / 可以 / 就这样 / 改吧 / 开始 → 进入执行
- 收到无关回复 → 追问「是确认方案，还是要改？」
- 收到修改意见 → 更新方案再输出，等再次确认
- 用户只是问问题（「这个方案有什么问题吗」「再想想」）→ 视为未确认，完善方案
第四步：执行纪律
- TodoWrite 建执行清单，不靠脑子记（清单革命）
- 逐项执行、每项验证后再走下一步（结硬寨打呆仗）
- 被阻塞（缺资料/冲突/异常结果）→ 停下问用户，不绕过、不 hack、不注释报错
- 不自动 commit、不自动 push（红线，任何时候先问）
- 完成后：结论先行汇报（做了什么 / 验证结果 / 遗留问题），给明确结束信号（下一步可做什么）
第五步：阶段确认（仅 D 类）
每完成一个阶段：
- 汇报该阶段结果（结论先行）
- 给出下一阶段方案
- 等确认后再继续——一次批准只覆盖到下一个确认点
场景衔接
- 论文写作（D 类）：整章拆节；每节动笔前给「节方案」——段落论证结构（论点→证据→结论）、引哪些来源、与前后文衔接；写完一节汇报，确认后再写下一节
- Stata 实证（D 类）：研究设计（假设→模型→变量→数据）整体确认后才开跑；每个 do-file 是独立确认点（衔接「分步骤保留独立 do-file」纪律）
- GitHub 协作（C/D 类）：方案块 + 项目既有闭环流程；push 是红线，任何时候先问
- 小工具开发（B/C 类）：常规流程
- 紧急中断指令（「算了」「停下」「别跑了」）优先于一切：立即停止，清理残留进程（Stata 场景先 taskkill），再处理新请求
例外清单
- A 类只读任务：无需方案
- 用户明确说「直接改」「小事」：走 B 类一句话确认
- 红线动作即使方案已确认，仍单独再问一次（删除 / push / 密钥 / 安装 / 发布）
- 拿不准是否变更：按变更对待，先确认