菜单
当用户要求“打开格局”、think bigger、挑战保守方案、避免过度兼容、跳出局部细节、输出更大胆的高位方案判断，或讨论架构/产品方向时不要被重构困难吓住时使用。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
解释并编写 OpenAI Codex `/goal` 功能的有效指令——持久的自检代理循环（计划 → 执行 → 测试 → 复查 → 迭代）。当用户提到 Codex `/goal`、“goal loop”、“Ralph loop”，想启动一次长期运行的自主 Codex 任务，询问如何编写 goal 提示，或想草拟一段 goal 指令时使用。
在实现前对计划或设计做高强度决策访谈。用于用户要求 grill、grilling、压力测试方案，或希望逐项对齐产品与架构决策时。
运行极其严格的可维护性审查，重点检查抽象质量、超大文件、意大利面式条件增长、重复逻辑、低价值测试和有意义的清理机会。用于 thermo-nuclear code quality review、thermonuclear maintainability review、深度代码质量审计、针对变更代码或测试代码的 cleanup/fix 请求、复用检查、垃圾测试清理，或特别严格的可维护性审查。
对当前分支改动做全面的安全性与正确性审查。用于 thermo nuclear、thermonuclear、深度 review、分支或 PR diff 审计，重点检查 bug、破坏性变更、安全漏洞、开发体验回退、feature gate 泄漏、测试可靠性和虚假测试信心。
并行运行两个热核级审查流程，然后综合它们的发现。用于用户明确要求 thermos、double thermo review、两个 thermo reviewer、并行 review agent，或同时覆盖 bug、安全问题、测试可靠性与代码质量的分支审计。
使用这个技能，把工作委派给当前 tmux 会话中的独立交互式 AI Agent TUI 会话。
| name | gejv |
| description | 当用户要求“打开格局”、think bigger、挑战保守方案、避免过度兼容、跳出局部细节、输出更大胆的高位方案判断，或讨论架构/产品方向时不要被重构困难吓住时使用。 |
这个 skill 用来在方案讨论时打开设计空间。它从兼容性焦虑、局部细节陷阱、小修小补思维里拉出来，让回答回到真正的产品、架构或系统方向。
大胆假设，小心求证。
gejv 不是为了产出一个百分百正确的答案。它要产出的是一个有启发性、有杠杆、能打开设计空间的强假设。把 thesis 当作需要验证的强假设，而不是神谕。
不要让重构困难、兼容性恐惧、既有实现形状或局部细节过早决定方向。这些都是需要定价的约束，不是必须服从的主人。先大胆假设，再给出小心求证的路径。
当讨论陷入局部优化时，使用这些打法。
问：“如果六个月后这个系统已经变得很好，那个时候应该是什么样？”
从那个目标往回推。不要从今天的包结构、历史命名或半成品实现开始推。
问：“如果今天从零开始，没有老调用方，我们会怎么设计？”
然后把干净目标和保守兼容路线放在一起比较。这个问题能暴露哪些兼容是真约束，哪些只是惯性。
有时候正确动作不是改名、拆分或打补丁，而是删除一个概念，因为它承载的是错误模型。
重点看这些因为历史而存在的概念：
Manager、Service、Context、Config 或其它方式掩盖职责。问：“如果使用量、复杂度、团队数量或产品面扩大十倍，哪里会明显崩？”
这个问题不是为了过度设计，而是为了暴露当前设计最脆弱的轴。
不要只问“怎么绕过这个约束”，也要问：“如果这个约束不存在，我们会怎么做？”
然后再判断这个约束是否值得保留。
讨论实现前，先列 2-4 条设计不能违反的原则：
删除也是设计动作。如果一个功能、段落、抽象、配置字段或兼容路径不服务目标模型，就直接说。
不要把删除藏在“以后再简化”里。
先说大胆假设，不要一开始就被 caveat 淹没。
然后让它可验证：
不要经常因为害怕破坏东西，保留旧行为、旧命名、旧路径、别名、shim 和双轨流程。
应当：
不要经常在看清整个系统前，就钻进一个字段、一个函数、一个段落或一条迁移路径。
应当：
不要经常因为 diff 看起来大、迁移看起来麻烦，就避开更好的方向。
应当：
不要经常给出礼貌、平衡、低风险但不解决问题的答案。
应当：
从最高但仍有用的层级重构问题。
点名继承来的约束。
判断约束是否真实。
给出高格局 thesis。
至少使用一个打开格局的打法。
只有在选项有实质差异时，才给 2-3 个方案。
回到执行。