技能介绍

问题：模糊想法直接编译成 `/goal`，跑几小时后才发现跑偏

把一个想法丢给 Codex 的 /goal 长时间自主执行，最常见的失败模式不是模型能力不够，而是目标本身不合格：验收标准不可测量、没有快速反馈循环、上下文只活在对话里，用户在长跑过程中既看不见也调不动。这个技能把「把粗糙想法变成可执行目标契约」本身当成一个流程来处理，而不是一次性的 prompt 生成。

核心能力与关键步骤

四种模式，按最小成本选择：Interview（只有模糊想法时先访谈）、Tighten（已有 SPEC.md，专门挑战歧义）、Compile（规格合格后编译成 GOAL.md）、Check config（检查 Codex 配置是否支持自主长跑）。
访谈模式有硬门槛：在 done_when 包含用户确认过的具体验收标准之前，禁止编译 /goal prompt。访谈会覆盖技术实现、数据模型、边界情况、权衡、评分方式、反馈循环速度和验证手段。
Tighten 模式只收紧不加范围：每个歧义点要解释它为什么重要、给出两种不同解释、推荐更易维护的那个，只有涉及产品意图时才问用户；无法验证的内容直接移除或标记。
编译模式逐项过闸：done_when 必须指向具体命令、文件产物或可观察行为；scorecard 要说明主指标、阈值、回归检查和停止条件；feedback_loop 要说明快速检查的运行时间和代理有效性；长跑任务还要配工作记忆文件（PLAN.md、ATTEMPTS.md、NOTES.md）和人工控制面（CONTROL.md）。
配置检查是只读的：scripts/inspect_codex_config.py 报告 Codex 版本、已选配置键和与自主 /goal 的差距，不会自动改 ~/.codex/config.toml；只有用户明确要求才改，且危险的 never 审批与完全沙箱放行只针对显式信任的项目路径。

适用边界

优先用于编码和仓库工作。纯探索性、只做调研、安全关键，或缺少可验证完成标准的任务，应该让用户留在循环里，而不是编译 /goal。
长跑目标需要的是运行时 harness，不是一段任务描述：scorecard、feedback loop、working memory、human control surface 四个显式块缺一不可。
GOAL.md 写完后还要自检一轮，确认验证可执行、约束能挡住明显的捷径、任务确实足够面向执行。