melech-pre-plan

用途

melech-pre-plan 用于在计划、PRD 或实现开始之前，先达成一个共享的设计概念。它明确自己不是 plan mode，而是阻止 plan mode 过早发明错误东西的阶段。用户拥有决策权，该技能只负责打开真正重要的分支，其余默认处理，并在概念足够共享、可以构建时停止。

主要能力

Effort 分级

Effort 控制可以打开多少个关键决策，而不是问多少琐碎问题或“思考”多用力。支持显式覆盖：

melech-pre-plan light
melech-pre-plan / melech-pre-plan standard
melech-pre-plan deep

未指定时，根据任务自动校准，并用一行简短说明选择了哪一档。

各档位对应场景与问题数量：

light：清晰的 bugfix、局部改动、已有模式；0–2 个问题；仅在名词冲突时处理通用语言；始终执行规模门禁；仅在非平凡时执行挑战环节。
standard：新功能路径、完成定义不清晰、触及边界；3–7 个批量问题；刷新实际使用的术语；始终执行规模门禁；挑战环节可选。
deep：新领域概念、多模块、数据模型/规模/产品模糊，或反复出现错位；对关键分叉进行设计树遍历；打开或更完整地处理通用语言；始终执行规模门禁；始终执行挑战环节。

自动判断经验法则：

light：约一个文件、复现明显、验收清晰
standard：功能形态、完成定义模糊、跨模块/API 边界
deep：新名词、多种有效架构、规模声明，或该区域“AI 总是抓不住重点”

更高 effort 意味着更多架构/范围/正确性/排序分支，而不是更多按钮文案或文件夹布局问题。

问题过滤

只有当答案会改变以下至少一项时，才问下一个问题：

构建什么 vs 跳过什么
系统边界或数据模型
失败模式/正确性标准
排序（先交付什么）
是否在为规模过度构建

否则从代码库、技术栈和团队约定中假设。优先批量分叉（2–4 个明确选项），而非长时间串行来回。一个高杠杆问题胜过五个礼貌性澄清。不要问那些应该默认的繁琐实现细节，除非它们是任务核心。

使用方式

工作流

只运行所选 effort 需要的阶段。light 可自由跳过。

定位请求：用一句话说明这是什么——现有路径内的修复/局部改动、功能或工作流变更、新领域概念或相邻产品形态。如果不清楚，给出可能的解读并问一个直接问题。
通用语言（默认轻量）：为本次会话维护工作词汇——首选术语、禁止/过载的同义词、重要的模块或边界名称。light 仅在名词冲突时处理；standard 刷新实际使用的术语；deep 打开或更新该区域的简短词汇表。在后续每个问题和最终决策日志中使用这些术语，不要发明平行词汇。
对齐设计概念：建立对所构建事物的共享理解——Brooks 的设计概念，而非 markdown 资产。按顺序遍历决策依赖：依赖早期选择的后续选择等待。一次解决一个关键分叉（或一小批独立分叉）。随时记录：目标/完成定义、范围内/范围外、关键边界与接口、假设的默认值、开放风险。当进一步提问不再改变概念时停止。
规模门禁（始终执行）：在概念固化前运行此清单。任何“是的我们需要花哨的 X”都需要证据。
- 我们实际接近什么限制？证据是什么？
- 我们是在为下一个数量级设计，还是为幻想规模设计？
- 问题是具体的，还是为假设未来准备的通用工具箱？
- 垂直/更简单的选项能否让我们度过下一阶段？
- 能否推迟缓存、分片、新框架和广泛抽象？
如果概念包含过早架构，剥离它或让用户有意识地接受成本。偏向具体 > 通用，简单 > 状态，当跑道真实时今天够用就好。
挑战环节（后期，受 effort 门控）：仅在方向存在后执行。light 跳过，除非改动意外地沉重；standard 在概念变重时可选；deep 始终执行。用稀疏的高价值问题施压：弱权衡、隐藏约束、过度工程、实现者绝不能猜测的任何事。除非概念明显破裂，否则不要从零重启。不要把它变成 PRD。如果结构比文字更容易看清，画紧凑的 ASCII。
在共享理解处停止：默认输出是简短的决策日志，而非计划——共享概念（5–10 行）、关键决策、假设默认值、规模门禁结果、剩余风险/不可猜测项、建议的下一步：实现最小有用形态、测量边界，或锁定它。不要自动写完整计划、PRD 或 issue 分解。仅在用户明确说锁定它/计划它/写 issue 时才写那些。如果边界选择仍需要数字（缓存键形态、索引、访问模式、队列语义），说明并停止——建议进行测量比较而非凭感觉。不要假装问答可以替代基准测试。

Do / Don't 示例

Do：“Auto → standard。两个分叉重要：复用现有 Invoice 模型 vs 新 CreditNote 原语；以及同步 vs 异步副作用。其余我从 billing 模块默认。”

Don't：问 40 个关于命名、文件夹和按钮标签的问题。

Do：“规模门禁失败：概念中有 Redis + 通用缓存框架，但没有证据表明我们接近限制。建议推迟缓存，直到端点被测量。”

Don't：让 k8s / 分片 / “为了规模”因为听起来负责任而搭便车。

Do：“共享概念已锁定在决策日志中。如果你想要计划/issue，说锁定它；否则我可以把它带入最小有用实现。”

Don't：问题一慢下来就跳进多节 PRD。

Do：对清晰的空值检查 bug 使用 melech-pre-plan light：确认复现 + 验收，规模门禁 N/A，完成。

Don't：对一行修复运行深度拷问。

适用场景

在开始规划或编码前，需要先对齐设计概念
任务存在多个有效架构或范围模糊
完成定义不清晰，或反复出现理解错位
需要控制关键决策数量，避免过度提问或过度设计

限制

该技能不是 plan mode，不自动生成完整计划、PRD 或 issue 分解
默认输出为简短决策日志，而非详细文档
不替代基准测试，边界选择需要数字时应停止并建议测量
具体收费、价格、平台支持等信息暂未提供