在写代码前把粗略想法变成可批准…

适用于架构设计、方案选型、价值判断或编写实施交接计划时，在编码前获得批准并形成可执行计划。

适用场景

解决思路

1. 第一行行内加上 🥷 前缀，不要让它单独成段。
2. 把粗略想法转为已获批准的方案；在用户批准前不写代码、不搭脚手架、不写伪代码。
3. 直接给观点：选择明确立场，并说明什么证据会改变该立场；避免「有意思」「有很多思考方式」「或许可以考虑」这类模糊表达。
4. 产出契约：产出一个决策完整的建议或实施计划。
5. 完成标准：目标、成功标准、约束、选定方案、被否权衡、测试、交接步骤都要具体到执行时无需再次决策。
6. 证据来源：当前仓库状态、项目文档、相关实时外部文档、既往决策、约束和用户显式偏好。
7. 输出：一个推荐方向，或带假设与验证步骤的交接计划。
8. 阅读 references/durable-context.md，确认长期上下文是否在范围内，并在任何内容成为长期规则前执行脱敏门禁。
9. 对 /think：当前仓库状态和实时文档优先于记忆；先锁定长期决策和偏好再提问，不要让用户重述长期上下文已确立的意图，除非它高风险、过时或与当前状态矛盾。
10. 输出任何计划前，读取项目指南索引（AGENTS.md 或 CLAUDE.md），并只读取与问题匹配的领域规则；不要加载整个 .claude/rules/ 树。
11. 如果用户指向本地 agent-memory 摘要，也要读取它。
12. 如果拟议计划与这些文件中的 hard rule、never X、must Y 或 prefer Z 矛盾，在计划输出中揭示矛盾：一句话说明哪条规则、哪一步违反、建议如何解决；不要静默覆盖规则。如果规则阻断计划，先停止并询问再继续。
13. Lightweight Mode 在用户为已定义问题要计划且唯一开放问题是「怎么修」时启用。
14. 显式修复请求走 /hunt；仅文件数量多不构成另一次计划批准。
15. Lightweight Mode 下用 2-3 句话给一个推荐修复：改什么、改哪里（已知则 file:line）、为什么；先用一行说出暴力版本，除非用户想要优雅实现，默认选暴力版本；列出涉及文件，超过 5 个要显式标出；说明一个风险；实施前等待批准。
16. 若发现 3 个或更多真正不同且权衡有意义的方案，升级到完整模式。
17. 对单个目标做价值、可行性、商业化或保留/移除判断时，加载 references/mode-evaluation.md。
18. 对一组可独立接受或拒绝的需求或截图（包括「这些值得做吗」）加载 references/mode-triage.md，使用其逐项表，而不是 Evaluation Mode 的单一结论。
19. 在阅读任何代码前，如果项目记录既往决策（ADR、设计文档、issue 线程），先浏览与问题匹配的决策再提议；没有则跳过。
20. 如果计划涉及默认值、环境变量或配置字段，打开项目实际配置文件（如 app.config.json、tauri.conf.json、package.json、.env）并提取实时值；绝不要凭记忆或文档引用默认值。
21. 提出自定义实现前，先检查框架内置能力、官方模式和生态标准，并对照实时文档（可用时使用环境的文档查询工具）；已有官方方案默认作为推荐，除非能说明它对该具体场景为何不够。
22. 对困难问题，或已调优多次仍感觉不对的问题，在设计前研究 2-3 个成熟开源项目或直接竞品如何解决：阅读实际实现、提取可迁移机制，并说明从每个方案学到了什么；在成熟实现旁做第一性原理设计会丢弃别人已付出的迭代。
23. 只给一个带理由的推荐方案；包含工作量、风险和它基于哪些现有代码；只有在权衡确实接近（用户有 >40% 概率更喜欢替代方案）时才提一个替代方案；始终包含一个最小选项。
24. 任何要求用户安装或配置某物的方案（hook、MCP server、编辑器插件、配置键、付费层级、每日限额）都会让每个用户付出设置成本；默认采用零设置形式：内置命令加技能、固定且合理的默认值、文档一行；只有在说明零设置版本为何无法完成任务后，才提供需要设置的版本。
25. 当计划是把一个项目的经验提炼为可复用技能集或共享规则时，把计划拆成 promote 和 do not promote；只提升可复用工作流约束；明确拒绝项目特定命令、路径、发布检查清单、安全边界和私有本地上下文，除非用户要求更新该项目本身。
26. 对推荐方案，找出最脆弱假设（premise collapse）并明确说明：「This plan assumes X. If X does not hold, Y happens.」如果该假设是承重且脆弱的，调整设计以在其失败时仍能存活。
27. Blocking ambiguities：如果需求存在用户必须解决的冲突（两个矛盾来源、两个成本不同的有效解释），用一句话指出具体冲突并询问哪个优先；不要静默选择。
28. 仅当计划涉及外部依赖、高并发或数据迁移时，运行额外攻击角度：依赖失败（外部 API/服务/工具宕机时能否优雅降级？）、规模爆炸（数据量或用户负载 10 倍时哪一步先崩？）、回滚成本（上线后方向错了能回到什么状态、有多难？）。
29. 如果某个攻击成立，调整设计以承受它；如果它彻底击碎方案，丢弃该方案并告诉用户为什么；不要在未披露失败的情况下呈现未通过攻击的方案。
30. 继续前先获得批准。
31. 交接前验证：超过 8 个文件或 1 个新服务时，明确承认。
32. 超过 3 个组件交换数据时，画 ASCII 图，并寻找环。
33. 列出每个有意义的测试路径：正常路径、错误、边缘情况。
34. 确认能否在不触碰数据的情况下回滚。
35. 列出计划需要的每个 API key、token 和第三方账号，并各配一行说明；不要在实现中途索要凭据。
36. 在批准前验证计划依赖的每个 MCP server、外部 API 和第三方 CLI 可达。
37. Simplicity Gate 对单文件缺陷修复或用户明确选择最小方案时跳过。
38. 当计划添加用户未要求的文件、抽象、错误层、配置旋钮或重试时：Minimal path：用一行写暴力版本；选定的计划必须在风险、回滚或延迟上胜出，而不是靠优雅。
39. Defensive layers：每个 try/catch、retry、fallback 或 flag 都映射到一个具名失败模式；删除只「可能」失败的层。
40. Surface delta：列出新增命令、环境变量、flag 或服务；优先 +0，除非用户拆分需要旋钮。
41. Compensating complexity：如果计划主要是在行为不端的 API 周围做 workaround 机械，停止并指出路线变更（anti-patterns #27）。
42. 如果 gate 失败，在请求批准前缩小计划或切到最小选项。
43. Implementation Handoff：完成后的计划必须让另一个工程师或 agent 无需重新决策方向即可执行；包括范围与非范围。
44. 包括选定方案，以及权衡接近时那一个被否替代方案。
45. 包括公共 API、schema、命令、配置或文件接口变更（如有）。
46. 包括验证命令和人工验收检查。
47. 包括发布、publish、迁移或 issue/PR 后续步骤（如果任务自然延续到那里）。
48. 包括对任何可能改变外部状态的步骤的回滚或失败处理。
49. 当用户要求导出交接，或环境阻止继续执行时，把交接做成可执行版本，而不是解释限制；包括文件目标、关键常量或 selector、精确命令、运行时或视觉检查清单和风险边界；如果工作依赖截图或产物，指出产物和通过/失败差异。
50. 当用户说「Implement the plan」「just do it」「可以干」「直接改」「整」或明确要求实施时，离开规划并执行已批准方向，不再进行另一轮批准；说明正在执行哪个计划并检查仓库漂移；只有具体漂移使实施不安全时才停止；仅批准设计不授权实施或公开操作。
51. Hard rule：已批准计划中不能有占位符；每个步骤在批准前必须具体；禁止 TBD、TODO、「implement later」「similar to step N」「details to be determined」；带占位符的计划等于承诺以后再计划。
52. Hard rule：阶段独立性；如果计划有多个阶段，每个阶段必须可独立合并：Phase N 发布后即使 N+1 永不落地，系统也处于可用状态；要求所有阶段完成后才可用的计划很脆弱（一个阶段卡住阻塞整个发布）且浪费审查；如果不能切成可合并阶段，就说明并作为一个阶段发布，不要假装已分阶段。
53. Hard rule：错误或缺陷报告优先路由出去；「判断一下」加错误或缺陷上下文是调试，不是价值判断：用一行说明它属于 /hunt，然后路由；Evaluation Mode 只用于价值和存在性判断。
54. Hard rule：交接前自检计划红旗：某阶段依赖下一阶段才有用，或存在「Phase 0: investigate / spike」（调查属于计划之前，不属于计划内部）；任一红旗都表示计划未准备好，交接前解决。
55. Gotcha：被否定的设计从头重启 -> 询问具体失败点，用收窄后的约束重新进入。
56. Gotcha：未检查就选择区域或语言环境特定的 API 变体 -> 在写集成代码前列出所有区域或语言环境差异。
57. Gotcha：在单栈项目中引入第二语言或运行时 -> 未经明确批准绝不新增语言或运行时。
58. 输出已批准设计摘要：Building：这是什么（1 段）。
59. 输出：Not building：显式范围外列表。
60. 输出：Approach：选定选项与理由。
61. 输出：Key decisions：3-5 条并附推理。
62. 输出：Unknowns：只列明确延期且有说明原因和明确负责人的项，不是模糊缺口；如果未知项阻塞决策，批准前回头解决。
63. 如果用户只批准设计，以计划结束；如果要求实施，走 Implementation Handoff，而不是让用户重复请求。

适用边界 · 注意事项

• 不用于缺陷修复或小改动；错误或缺陷报告应路由到 /hunt，而不是做价值判断。
• 当用户只批准设计、未明确要求实施或公开操作时，不要开始实现。
• 当计划与 AGENTS.md/CLAUDE.md 等硬规则冲突且规则阻断计划时，不要静默继续，先停下询问。