Codex Goal — Run goal-maker boards in Codex

/goal-maker bootstraps the board. /codex-goal runs the PM loop in Codex — same shape as /codex-review but for goal execution instead of code review. Claude Code stays the orchestrator; Codex does one PM iteration per invocation, leaves a receipt in state.yaml, and Claude reads it back.

Principle #10 (Agents drift, gates don't) — the checker (check-goal-state.mjs) runs before the Codex invocation (refuse to delegate to a broken board) and after (verify the board is still valid post-edit). Both gates are non-bypassable. Principle #7 (Reversibility) — one task per invocation by default; the human stays in the loop between iterations unless they explicitly opt into --continue. See /principles.

Why hand off to Codex at all

Two reasons:

1. Cost. gpt-5.5 at low reasoning is dramatically cheaper than running the same loop in Claude Opus. For Worker tasks (bounded scope, deterministic verify commands), low reasoning is exactly the right effort.
2. Context isolation. Each Codex exec invocation is a fresh session. The PM loop in goal.md plus the active task in state.yaml is all the context the Codex thread needs — no Claude conversation history bleeds in. This is the same discipline goal-maker is built around.

Reasons NOT to use this — keep the loop in Claude:

• Active task is Judge on a high-stakes call (use high reasoning, do it in Claude Opus or Codex with -c model_reasoning_effort=high)
• You're actively iterating on the goal/charter and want to see Claude's reasoning per turn
• The task involves a domain Codex hasn't been given context for in CLAUDE.md (Codex won't auto-load CLAUDE.md the same way)

When to use