用途
pre-plan 用于在编写计划、PRD 或开始实现之前，先达成一个可构建的共享设计概念。它明确声明自己不是 plan mode，而是阻止 plan mode 过早发明错误东西的阶段。用户拥有决策权，pre-plan 的职责是只打开真正重要的分支，其余全部默认，并在概念足够共享、可以开始构建时停止。
主要能力
努力档位（Effort）
努力档位控制的是可以打开多少个有后果的决策，而不是问多少琐碎问题，也不是“思考”得多用力。支持显式指定：
- pre-plan light
- pre-plan / pre-plan standard
- pre-plan deep
如果未指定，则根据任务自动校准，并用一行简短说明选择了哪一档。
各档位对照：
- light：适用于清晰的 bugfix、局部改动、已有模式。问题数 0–2，仅在名词冲突时处理统一语言，规模门禁始终执行，挑战环节仅在非平凡时执行。
- standard：适用于新功能路径、完成定义不清晰、触及边界。问题数 3–7 个批量提出，刷新实际使用的术语，规模门禁始终执行，挑战环节可选。
- deep：适用于新领域概念、多模块、数据模型/规模/产品歧义，或反复出现理解偏差。对关键分叉进行设计树遍历，打开或更完整地处理统一语言，规模门禁始终执行，挑战环节始终执行。
自动判断经验法则：
- light：约一个文件、复现明显、验收清晰
- standard：功能形态、完成定义模糊、跨越模块/API 边界
- deep：出现新名词、多种可行架构、规模主张，或该领域“AI 总是抓不住重点”
更高档位意味着更多架构/范围/正确性/排序分支，而不是更多按钮文案或文件夹布局问题。
问题过滤器
只有当答案会改变以下至少一项时，才问下一个问题：
- 构建什么 vs 跳过什么
- 系统边界或数据模型
- 失败模式/正确性标准
- 排序（先交付什么）
- 是否在为规模过度构建
否则从代码库、技术栈和团队惯例中假设。优先批量分叉（2–4 个尖锐选项），而不是长时间串行来回。一个高杠杆问题胜过五个礼貌性澄清。不要问那些应该默认的繁琐实现细节，除非它们是任务核心。
使用方式
只运行所选档位需要的阶段。light 档可自由跳过。
1. 放置需求
用一句话说明这是什么：
- 修复/已有路径内的局部改动
- 功能或工作流变更
- 新领域概念或相邻产品形态
如果不清楚，给出可能的解读并问一个直接问题。
2. 统一语言（默认轻量）
为本次会话维护一套工作词汇：
- 首选术语
- 禁止/过载的同义词
- 重要的模块或边界名称
light 档仅在名词冲突时处理。standard 档刷新实际使用的术语。deep 档打开或更新该领域的简短词汇表。在后续每个问题和最终决策日志中都使用这些术语，不要发明平行词汇。
3. 对齐设计概念
建立对所构建事物的共享理解——Brooks 的设计概念，而不是 markdown 资产。按顺序遍历决策依赖：依赖早期选择的后续选择要等待。一次解决一个有后果的分叉（或一小批独立分叉）。边做边记录：
- 目标/完成定义
- 范围内/范围外
- 关键边界和接口
- 假设的默认值
- 开放风险
当进一步提问不再改变概念时停止。
4. 规模门禁（始终执行）
在概念固化之前，运行此清单。任何“是的我们需要花哨的 X”都需要证据。
- 我们实际接近什么限制？证据是什么？
- 我们是在为下一个数量级设计，还是为幻想规模设计？
- 问题是具体的，还是为假设未来准备的通用工具箱？
- 垂直/更简单的选项能否带我们度过下一阶段？
- 我们能否推迟缓存、分片、新框架和宽泛抽象？
如果概念包含过早架构，剥离它或让用户有意识地接受成本。偏向具体 > 通用，简单 > 状态，当跑道真实时今日够用即可。
5. 挑战环节（后期，受档位控制）
仅在方向存在之后进行。light 档跳过，除非改动意外地沉重。standard 档在概念变重时可选。deep 档始终执行。
用稀疏的高价值问题施压：
- 弱权衡
- 隐藏约束
- 过度工程
- 实现者绝不能猜测的任何事
除非概念明显破裂，否则不要从零重启。不要把它变成 PRD。如果结构比文字更容易看清，画紧凑 ASCII 或使用 visualize。
6. 停在共享理解
默认输出是简短的决策日志，而不是计划：
- 共享概念（5–10 行）
- 关键决策
- 假设的默认值
- 规模门禁结果
- 剩余风险/不可猜测项
- 建议的下一步：通过 8020 实现、测量边界，或锁定
不要自动编写完整计划、PRD 或 issue 分解。只有当用户明确说锁定它/规划它/写 issue 时才写。
如果边界选择仍需要数字（缓存键形状、索引、访问模式、队列语义），说明并停止——建议进行有测量的比较，而不是凭感觉。不要假装问答可以替代基准测试。
与兄弟技能的关系
- challenge：对已有计划/方向进行独立戳刺。pre-plan 可能运行后期挑战环节；当不需要仪式时使用独立 challenge。
- distill-need：当需求可能是提议的解决方案/更快的马时先运行。pre-plan 假设工作已经是构建形态。
- 8020：对齐之后，选择最小的有用实现形态。
- product-ideation：更早/更广的产品前提工作。当用户准备好对齐可构建概念时交给 pre-plan。
- visualize：当结构/流程模糊时的可选辅助。
适用场景
- 在开始写计划或代码之前，需要先对齐设计概念
- 需求完成定义模糊，需要澄清关键分叉
- 担心过早引入架构或为幻想规模设计
- 需要控制提问密度，避免琐碎问题
限制
- 不自动编写完整计划、PRD 或 issue 分解，除非用户明确要求
- 不替代基准测试，边界选择需要数字时应停止并建议测量
- 不处理命名、文件夹、按钮标签等琐碎问题
- 不重启已确认的概念，除非概念明显破裂
- 关于收费、价格、平台支持等具体信息暂未提供