Next Goal

Discover the substantial next-goal scopes supported by repository evidence. Use a clear scope selected in the current or an earlier request. A request to choose the next goal delegates scope selection: choose the best supported boundary. When only one viable scope exists, select it unless the user requested a choice or preview first. Ask only when materially different outcomes remain unresolved by user direction or delegated judgment.

Revalidate the selected scope, pass the readiness gate, recommend PR delivery or later aggregation based on expected change size, and generate one compact fresh-session routing envelope with a closed execution contract. Scope selection does not require a separate user turn. Generate a non-recommended delivery prompt only when the user explicitly requests that variant, alone or alongside the recommendation.

Keep scope discovery and selection read-only. Preparation is a separately authorized phase described below; after it finishes, revalidate the same boundary from the resulting repository state. When returning a goal prompt, keep prerequisite results in commentary so the final response remains directly copyable into /goal. Put $progress goal tracking in the contract so the goal-running session initializes durable goal state.

Choose the Operation

These are explicit skill instructions, not shell commands:

Invocation	Authorized operation
`$next-goal`	Select and return a prompt; no mutation by default.
`$next-goal prepare`	Select, complete and review the detailed plan, commit relevant preparation, then return a prompt.
`$next-goal spawn [model] [reasoning]`	Prepare, then create one new Codex task from the prepared state and start a native goal there.

Honor an explicit prompt-only, preview, no-commit, or wait instruction over these defaults. A mention in a quote, example, or skill-design discussion does not request execution. Model arguments belong only to spawn; do not infer spawning from a model name alone. Keep explicit invocation policy unchanged.