Codex /goal template adds 6 fields for verification commands and stop conditions

• A community Codex workflow from aibuilderclub_'s thread turns /goal into a six-part contract: outcome, verification, constraints, boundaries, iteration policy, and a stop condition.
• The strongest example in aibuilderclub_'s prompt example swaps a vague "improve performance" ask for a target with a metric, a benchmark, and a constraint to keep tests green.
• An eight-item preflight list from aibuilderclub_'s checklist post adds setup checks like a clear verification command, an explicit stop rule, and a final report requirement.
• GoalBuddy's GitHub repo and GoalBuddy's project site package the same idea into a local goal.md plus state.yaml loop for broad or multi-day runs, echoing OpenAI's own guidance in Follow a goal and Using Goals in Codex.

OpenAI's own Codex docs already frame /goal as a persistent objective with a validation loop that can run for hours in Follow a goal. What the community thread adds is a more explicit shape for that objective, while GoalBuddy's README turns it into local files and a repeatable board. There is also a small but telling discoverability wrinkle: a June 5 commit in openai/codex had to fix /goal help text so pause, resume, edit, and clear were actually shown.

The useful bit here is not that Codex needs a better prompt. It is that the thread separates two things people often collapse into one sentence: the target itself, and the procedure for proving the target was hit.

The six fields in aibuilderclub_'s breakdown are:

1. Outcome: what done looks like.
2. Verification: how to prove it.
3. Constraints: what must not break.
4. Boundaries: what is in scope and off-limits.
5. Iteration policy: how to choose the next step.
6. Stop condition: when to stop and report.

That maps closely to OpenAI's own cookbook, where Using Goals in Codex defines a goal as a completion condition covering what should be true, how success should be checked, and what constraints must stay intact.

The preflight list is stricter than the six fields because it checks the operator as much as the prompt. aibuilderclub_'s checklist post asks for eight items before a run starts:

• Outcome specific
• Scope defined
• Acceptance criteria objective
• Verification command clear
• Codex told to keep fixing on failure
• Stop conditions set
• Plan mode exited
• Final report required

That seventh item lines up with the Codex manual, which recommends /plan for clarifying context and a done condition before implementation. The checklist effectively treats /plan as staging, then /goal as execution.

The helper-tool layer is where this turns from a prompt tip into an operating loop. aibuilderclub_'s tool post names two tools: /grill-me, which interrogates the user before the run, and GoalBuddy, which prepares a structured file for broader tasks.

According to GoalBuddy's README, the tool generates a goal.md charter, a machine-readable state.yaml board, role-tagged Scout, Judge, and Worker tasks, plus receipts and verification before completion. Its goal-prep command prepares the board and prints the /goal command to run next, rather than starting the run automatically.

The official Codex docs also expose more lifecycle control than the thread spells out. Follow a goal documents /goal pause, /goal resume, and /goal clear, and this openai/codex commit says the TUI help text had been advertising only the objective form even though those control commands were already implemented. That helps explain why mattlam_'s reply about /goal asked whether part of this behavior had been removed.