PLAN MODE 技能
触发条件
当用户使用 /plan 命令时，必须进入 PLAN MODE。
核心原则
第一产出永远是计划，不是代码。
在用户明确批准前，禁止：
- 写最终实现代码
- 修改文件
- 执行命令
- 做任何破坏性操作
工作流
收到 /plan 请求后，按以下顺序输出：
一、任务理解
简洁说明：
- 用户要解决什么问题
- 预期交付物
- 成功标准
- 已知约束
- 仍不明确的点
二、当前上下文
分析可见信息：
- 相关模块/文件/目录
- 依赖项与配置
- 接口或数据流
- 现有实现模式
- 可能受影响的逻辑
- 潜在风险点
三、缺失信息 / 关键假设
- 列出缺少但影响判断的信息
- 列出已采用的默认假设
- 仅在必要时提出最多 3 个关键问题
四、实施计划
给出 3-8 步计划。每步说明：
- 做什么
- 为什么
- 影响哪里
- 预期产出
五、影响范围
列出涉及：
- 文件、模块、配置
- 接口、数据结构
- 测试、文档
六、风险点
指出：
- 最易出错处
- 可能回归点
- 兼容性/性能/安全/维护成本风险
- 是否有更小范围替代方案
七、验证方案
说明如何确认成功：
- 功能验证
- 测试策略
- 边界场景
- 回归检查
- 用户可见行为变化
八、待确认事项
只列真正影响实施路径的决策点，并给出推荐方案。
九、停止并等待批准
输出计划后必须停止。
只有收到以下批准语句后才进入执行阶段：
- "执行"
- "开始实现"
- "按这个计划做"
- "approved"
- "go"
输出格式模板
## 任务理解
...
## 当前上下文
...
## 缺失信息 / 关键假设
...
## 实施计划
1. ...
2. ...
3. ...
## 影响范围
- ...
## 风险点
- ...
## 验证方案
- ...
## 待确认事项
- ...
## 下一步
等待用户批准后再执行。
执行切换规则
用户批准后切换到 EXECUTION MODE：
1. 严格按批准计划实施
2. 发现重大偏离时先暂停说明
3. 小调整可说明后继续
4. 持续同步进展，不重复整份计划
信息不足时
优先基于现有上下文做合理假设并明确写出。只有在确实影响方案选择时，才提出少量关键问题。
