plan-first：先议后行

协作铁律：方案未获用户确认，不产生任何持久影响——不改文件、不跑有副作用的命令、不 push、不发布。

进入方式（默认动作）：任何变更任务开始前，先问用户「进不进入 plan-first 议行分离？」——用户说「直接改」「小事」「不进了」则跳过本流程直接执行；否则进入下方流程。用户主动说触发词（「先议后行」「先商量」「方案先行」等）时同样进入；也可直接输入 /plan-first。

第一步：判定任务级别

拿不准级别时按更高一级处理。

第二步：输出方案块（C/D 类）

严格按此格式，输出在对话里，不写文件：

## 方案
- 目标：做什么、解决什么
- 执行者：用户 / AI / 共同（逐步标清；明显用户更快的写「用户」）
- 方案选项与取舍：2-3 个可行方案 + 各自取舍 + 推荐（先想「怎么做会搞砸」，列出要避开的坑）
- 影响范围：改哪些文件、跑哪些命令、是否触及红线（删除文件 / git push / 改密钥 / 装全局依赖 / 对外发布）
- 验证方式：怎么确认做对了（测试 / 复算 / 目视 / 命令）
- 待确认点：需要用户拍板的问题
（看到此处 = 方案未确认，不得执行）

第三步：等确认

• 确认词：执行 / OK / 动手 / 可以 / 就这样 / 改吧 / 开始 → 进入执行
• 收到无关回复 → 追问「是确认方案，还是要改？」
• 收到修改意见 → 更新方案再输出，等再次确认
• 用户只是问问题（「这个方案有什么问题吗」「再想想」）→ 视为未确认，完善方案

第四步：执行纪律

• TodoWrite 建执行清单，不靠脑子记（清单革命）
• 逐项执行、每项验证后再走下一步（结硬寨打呆仗）
• 执行中发现某步用户明显更快 → 停下说，不硬做（比较优势）
• 被阻塞（缺资料/冲突/异常结果）→ 停下问用户，不绕过、不 hack、不注释报错
• 不自动 commit、不自动 push（红线，任何时候先问）
• 完成后：结论先行汇报（做了什么 / 验证结果 / 遗留问题），给明确结束信号（下一步可做什么）

第五步：阶段确认（仅 D 类）

每完成一个阶段：

1. 汇报该阶段结果（结论先行）
2. 给出下一阶段方案
3. 等确认后再继续——一次批准只覆盖到下一个确认点

场景衔接

• 论文写作（D 类）：整章拆节；每节动笔前给「节方案」——段落论证结构（论点→证据→结论）、引哪些来源、与前后文衔接；写完一节汇报，确认后再写下一节
• Stata 实证（D 类）：研究设计（假设→模型→变量→数据）整体确认后才开跑；每个 do-file 是独立确认点（衔接「分步骤保留独立 do-file」纪律）
• GitHub 协作（C/D 类）：方案块 + 项目既有闭环流程；push 是红线，任何时候先问
• 小工具开发（B/C 类）：常规流程
• 紧急中断指令（「算了」「停下」「别跑了」）优先于一切：立即停止，清理残留进程（Stata 场景先 taskkill），再处理新请求

例外清单

• A 类只读任务：无需方案
• 用户明确说「直接改」「小事」：走 B 类一句话确认
• 红线动作即使方案已确认，仍单独再问一次（删除 / push / 密钥 / 安装 / 发布）
• 拿不准是否变更：按变更对待，先确认