Next Goal

Discover the substantial next-goal scopes supported by repository evidence, recommend the most appropriate one, and ask the user which scope to pursue. Always pause for explicit scope confirmation, even when only one viable scope exists or the invoking request names a preferred scope. Emit no /goal prompt in that scope-choice response.

After the user confirms a scope in a follow-up, revalidate it, 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. A clear selection or adjusted boundary in that follow-up is the confirmation; do not ask again merely to restate it. Generate a non-recommended delivery prompt only when the user explicitly requests that variant, alone or alongside the recommendation.

Keep scope discovery, recommendation, confirmation, and final selection 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 a confirmed 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. Present the Scope Choices

Build a concise choice set of materially distinct, substantial goal boundaries the user could authorize. 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.