技能介绍

问题从哪来

用 OpenAI Codex CLI（codex exec、单智能体）跑中大型、半自主编码任务时，常见失败不是「提示词不够长」，而是循环没有可机跑的 done? 判定、执行者与评估者同上下文自评、以及失败路径只能堆补丁。没有可运行检查就不算闭环——设计器从 principle.closedloopneedsacheck 出发，从检查反推 循环形状，而不是凭感觉选 altitude。

技能如何工作

机制是 SELECT → NEGOTIATE → FILL → VERIFY → PERSIST，并依赖 loop-principle KB（本技能不内嵌，按路径检索模板与节点 id，缺 KB 时需在报告中声明降级模式）。

SELECT：按 references/loop-selection.md 顺序回答 D0–D6（是否成环、分解 flat/staged、每阶段 pattern 与 check、自主度、并行、守卫、迭代节奏），写入 decision log。
NEGOTIATE：按 LOOPS 模型分离 planner / generator / evaluator 三个上下文（Codex 上对应三次独立 codex exec，评估者只读且对抗）；协商 contract.assertions[]，评 contract 不评空 spec。
FILL：产出符合 loop-design-shape 的 loop-design JSON（含 harness_primitives 等持久化磁盘状态、selection_log）。
VERIFY：lint_loop_design.mjs 全 PASS 后，用 fresh-reader 清单核对 falsifiable_when、薄 contract、角色是否真分离。
PERSIST：render_loop_doc.mjs 校验通过后写入项目 .loop/ 可运行 runbook（含 Codex CLI 运行前言）。

交付物包括决策日志、角色与 contract、JSON、lint 结果、fresh-reader 结论、质量 rubric 自评、当前瓶颈与残余风险，以及 loop 停止时需遵守的 run-report contract（成功指标须与完整性/损害指标配对）。

边界与注意

设计专用：只持久化设计与 runbook，不执行被设计的循环、不跑目标业务代码、不改 loop-principle KB。并行与 fresh evaluator 只能是 独立 OS 进程上的 codex exec（大 fan-out 可用 git worktree 并发），不要设计进程内 subagent。staged 设计须满足 linter 对角色分离与 contract 的约束；构建可能腐化为考古现场时，应预设 restart 而非无限 patch。

截图预览

使用场景

准备用 `codex exec` 多阶段完成跨目录重构前，先跑 D0–D6 选型，产出可过 `lint_loop_design.mjs` 的 loop-design 与 `.loop/` runbook。
自主 Codex 任务常「自评通过但实现仍错」时，在设计阶段拆分 planner/generator/evaluator 三次 exec，并协商可机评的 contract.assertions。
中型任务需要多 git worktree 并发 `codex exec` 时，在 FILL/PERSIST 阶段写清 D4 并行与 runbook 里的 Codex 运行前言。
任务规模已超出单次 prompt，却缺少可机跑 done 检查时，用 SELECT 从检查反推 flat/staged 子循环与每阶段 feedback_signal。

适合人员

用 OpenAI Codex CLI 负责中大型仓库改动的工程师，希望开跑前把循环写成可审查的设计 JSON，而不是堆叠提示词。
在团队内推广半自主编码、需要 maker-checker 与对抗评估流程的技术负责人，要先固化 roles 与 contract 再交给 agent 写码。
维护 loop-principle 知识库或 sibling 技能的 Agent 工作流作者，需要为 Codex 运行时正确映射磁盘状态与 evaluator 只读 exec。
多次自主迭代后代码变成补丁考古现场的同学，想在设计里预设 restart、on_failure 与 stop_conditions，再启动长期 codex 循环。