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, recommendation, selection, and finalization read-only. A combined request may separately authorize prerequisite mutation, such as committing completed planning work. Complete that distinct phase first under its applicable workflow, then discover scopes from the resulting repository state without further mutation. When selection produces a goal prompt, keep prerequisite results out of the final response so the entire response remains directly copyable into /goal. Put $progress goal tracking in the generated prompt so the goal-running session, not the selection phase, initializes durable goal state.

1. Establish Current State

1. Read applicable AGENTS.md files and resolve the authoritative active PLAN, TODO, ROADMAP, progress, or handoff documents. Honor user-named documents; otherwise follow repository conventions and links. When concurrent worktrees or scoped roadmaps exist, select the current worktree's planning namespace; read other scopes only for an explicitly requested aggregate goal. When no plan exists, infer candidates from instructions, code, tests, and history.
2. Inspect git status and recent history, then read only enough implementation and validation evidence to detect stale plan claims, completed work, real prerequisites, and blockers.
3. Identify candidate outcomes, constraints, missing evidence, and consequential unresolved decisions. Leave user-owned implementation questions for the readiness gate so every such question carries the delegation-or-repair choice; choosing the goal boundary belongs to the following scope-choice step.

This step is complete when the current project state, candidate outcomes, and their material gaps are verified against the repository rather than merely repeated from a plan.

2. Resolve the Scope

First apply an existing scope selection or delegated choice, or select the sole viable scope. If the boundary remains unresolved or the user requested options, build a concise choice set of materially distinct, substantial goal boundaries. Treat named slices and checklist items as planning units, not automatic options or stopping boundaries. Options may differ by outcome or by coherent stopping point, but do not enumerate every permutation of adjacent work. Prefer two to four options when the evidence supports them; never invent a weak option to reach a count.