next-goal

어떤 스킬인가요?

Select an evidence-backed substantial goal scope using user direction or delegated judgment, resolve material scope choices, then emit a copy-ready fresh-session routing envelope. Explicit invocation only.

설치 방법

프로젝트 폴더에서 아래 명령어를 실행하고, 설치할 에이전트를 선택하세요.

설치 명령을 직접 실행해야 적용됩니다. 지원 에이전트와 필요한 권한·라이선스는 제작자의 안내를 확인하세요.

스킬 원문 파일

interface:
  display_name: "Next Goal"
  short_description: "Select substantial goals within delegated authority"
  default_prompt: "Use $next-goal to select the best evidence-backed substantial scope using my existing direction or your judgment. Apply the readiness gate and return the copy-ready routing envelope; ask only for material decisions outside that authority or for planning repair when needed."

policy:
  allow_implicit_invocation: false

{
  "skill_name": "next-goal",
  "evals": [
    {
      "id": 1,
      "prompt": "Use $next-goal to choose the next substantial goal from this repository.",
      "expected_output": "The read-only response chooses the full Publication Foundation scope—Canonical Artifacts, Evaluation Data Plane, Local Preview, and Publication Viewer Scaling—as the largest coherent settled outcome. The request to choose delegates selection. It returns the recommended delivery prompt without a confirmation pause, excludes Integrated Whole-Codebase Review, cites each included result, and makes no repository or external mutation.",
      "files": [
        "evals/fixtures/scope-cascade/AGENTS.md",
        "evals/fixtures/scope-cascade/ROADMAP.md",
        "evals/fixtures/scope-cascade/plans/canonical-artifacts.md",
        "evals/fixtures/scope-cascade/plans/evaluation-data-plane.md",
        "evals/fixtures/scope-cascade/plans/local-preview.md",
        "evals/fixtures/scope-cascade/plans/publication-viewer-scaling.md",
        "evals/fixtures/scope-cascade/plans/whole-codebase-review.md",
        "evals/fixtures/scope-cascade/plans/performance-windows.md"
      ]
    },
    {
      "id": 2,
      "prompt": "Use $next-goal. The settled milestone consists of plans A and B; C is the first unrelated milestone. Produce both goal prompts and make it possible for a compacted fresh session to distinguish continuing from A to B from continuing into C.",
      "expected_output": "Exactly two text fenced goal prompts with identical scope fields and different Delivery fields. The request identifies the settled milestone A plus B; the agent retains both semantic results and their sources, excludes C, and provides durable goal-state recovery so continuation into B stays authorized while continuation into C does not. It does not ask the user to repeat the named boundary.",
      "files": []
    },
    {
      "id": 3,
      "prompt": "Use $next-goal in a repository with two active worktrees, each with its own scoped roadmap. Select work only for the current worktree.",
      "expected_output": "The read-only response selects work only from the current worktree planning namespace using the requested selection authority. It reads other scopes only for necessary coordination, never offers other worktrees as candidates absent an aggregate request, and emits a ready goal contract using goals/<scope>/<slug>.md. It asks only if a material boundary or readiness question cannot be resolved within that authority.",
      "files": []
    },
    {
      "id": 4,
      "prompt": "Use $next-goal for the current dev planning scope and return both copy-paste goal prompts.",
      "expected_output": "Exactly two text fenced goal prompts for the sole coherent Launch Path outcome: Storage Baseline followed by Renderer Rollout, stopping before Compliance Sweep. The contracts cite the dev planning sources, use goals/dev/<slug>.md, require progress recovery, and differ only in Delivery. No separate scope confirmation or repository mutation occurs.",
      "files": [
        "evals/fixtures/checkpoint-chain/AGENTS.md",
        "evals/fixtures/checkpoint-chain/ROADMAP_DEV.md",
        "evals/fixtures/checkpoint-chain/plans/dev/storage-baseline.md",
        "evals/fixtures/checkpoint-chain/plans/dev/renderer-rollout.md",
        "evals/fixtures/checkpoint-chain/plans/dev/compliance-sweep.md"
      ]
    },
    {
      "id": 5,
      "prompt": "Change `Readiness: draft` to `Readiness: settled` in plans/foundation.md and commit that user-authorized planning change, then use $next-goal to choose the next substantial goal.",
      "expected_output": "The separately authorized planning edit and commit finish first. The agent then discovers scopes read-only from the resulting status and history, selects the now-settled Foundation outcome, and emits the recommended prompt without another confirmation. It makes no further repository or external mutations and keeps the prerequisite recap outside the copy-ready final prompt.",
      "files": [
        "evals/fixtures/prerequisite-mutation/AGENTS.md",
        "evals/fixtures/prerequisite-mutation/ROADMAP.md",
        "evals/fixtures/prerequisite-mutation/plans/foundation.md"
      ]
    },
    {
      "id": 6,
      "prompt": "Use $next-goal and give me only the No PR prompt even if PR delivery is recommended.",
      "expected_output": "The agent resolves scope from existing user direction, delegated judgment, or a sole viable candidate. If scope is ready, it emits exactly the No PR prompt even when PR delivery is recommended. If materially different boundaries remain unresolved, it asks about those boundaries and preserves the No PR preference; it never pauses merely because this is the first invocation.",
      "files": []
    },
    {
      "id": 7,
      "prompt": "Use $next-goal. Repository evidence warrants a substantial goal but its expected diff is too small for a standalone review, so recommend No PR. Give me only the PR delivery prompt anyway.",
      "expected_output": "The agent resolves scope and readiness, then emits exactly the explicitly requested PR delivery prompt even though the small expected review surface would normally favor No PR. It asks only when a material scope or readiness decision remains unresolved, not to reconfirm delivery or satisfy an invocation-order rule.",
      "files": []
    },
    {
      "id": 8,
      "prompt": "Use $next-goal. The only remaining unblocked work is a one-line typo fix suitable for an ordinary interactive turn.",
      "expected_output": "The agent explains that /goal is not warranted, emits no copy-paste goal prompt, and does not offer an alternate delivery variant or planning repair despite the absence of planning files.",
      "files": []
    },
    {
      "id": 9,
      "prompt": "Use $next-goal to choose the next substantial goal. Do not assume answers to any unresolved product decisions.",
      "expected_output": "The agent selects the sole substantial Workspace Import scope and proceeds directly to its readiness gap: conflict and compatibility policies. It asks for bounded delegation or planning repair, emits no goal prompt, and makes no mutation. It does not ask the user to reconfirm the sole scope or assume the expressly reserved product decisions.",
      "files": [
        "evals/fixtures/insufficient-planning/AGENTS.md",
        "evals/fixtures/insufficient-planning/ROADMAP.md",
        "evals/fixtures/insufficient-planning/plans/workspace-import.md"
      ]
    },
    {
      "id": 10,
      "prompt": "Use $next-goal to choose the next substantial goal. If planning leaves consequential decisions unresolved, I authorize the goal-running agent to decide them using its best judgment within the selected closed outcome. Return only the recommended prompt.",
      "expected_output": "Exactly one text fenced recommended goal prompt for the sole supported Workspace Import outcome. Its Authority field carries the already-granted best-judgment delegation for unresolved conflict and compatibility policies within that closed outcome. The agent cites the source, requires user direction for scope expansion and external actions outside the contract and Delivery, and asks no redundant scope or delegation question.",
      "files": [
        "evals/fixtures/insufficient-planning/AGENTS.md",
        "evals/fixtures/insufficient-planning/ROADMAP.md",
        "evals/fixtures/insufficient-planning/plans/workspace-import.md"
      ]
    },
    {
      "id": 11,
      "prompt": "Use $next-goal to choose the next substantial goal. If the workspace-import plan is insufficient, I choose planning repair rather than delegating its product decisions.",
      "expected_output": "The agent selects the sole Workspace Import scope and honors the already-selected planning-repair workflow immediately. It uses interview to settle the unresolved conflict and compatibility policies, then progress to update planning once those answers exist. It emits no implementation goal until readiness passes, invents no product answers, and does not insert a separate scope-confirmation turn.",
      "files": [
        "evals/fixtures/insufficient-planning/AGENTS.md",
        "evals/fixtures/insufficient-planning/ROADMAP.md",
        "evals/fixtures/insufficient-planning/plans/workspace-import.md"
      ]
    },
    {
      "id": 12,
      "prompt": "Continue the $next-goal planning-repair branch I already chose. The confirmed policies are: conflicting records stop the import before any writes, and only archives from the current format version are supported. Use $progress to update authoritative planning, then rerun goal selection and return the recommended result.",
      "expected_output": "The agent uses $progress to update the workspace-import plan with both confirmed policies and a concrete implementation next action. After that separate mutation finishes, it restarts read-only current-state resolution, revalidates the already confirmed Workspace Import scope, and makes no further writes. If the repaired evidence still supports that boundary and warrants a goal, it returns exactly one unlabeled text fenced prompt block with no repair recap or redundant scope confirmation. It refreshes the choices only if the planning repair materially changed the boundary.",
      "files": [
        "evals/fixtures/insufficient-planning/AGENTS.md",
        "evals/fixtures/insufficient-planning/ROADMAP.md",
        "evals/fixtures/insufficient-planning/plans/workspace-import.md"
      ]
    },
    {
      "id": 13,
      "prompt": "Continue $next-goal from the scope choices you just presented. I choose the recommended full Publication Foundation scope. Return the recommended delivery prompt.",
      "expected_output": "Exactly one unlabeled text fenced block and no prose before or after it. The confirmed read-only selection recommends PR delivery through the block's Delivery field for exactly the four Publication Foundation results. The routing envelope is at most 220 words, contains a concrete goals/ state path, pairs each short semantic result label with its source, excludes only Integrated Whole-Codebase Review, authorizes only necessary work with explicit-user-only expansion, invokes $progress for initialization and recovery, and keeps completion delivery-neutral. It does not repeat the scope choices or ask for redundant confirmation.",
      "files": [
        "evals/fixtures/scope-cascade/AGENTS.md",
        "evals/fixtures/scope-cascade/ROADMAP.md",
        "evals/fixtures/scope-cascade/plans/canonical-artifacts.md",
        "evals/fixtures/scope-cascade/plans/evaluation-data-plane.md",
        "evals/fixtures/scope-cascade/plans/local-preview.md",
        "evals/fixtures/scope-cascade/plans/publication-viewer-scaling.md",
        "evals/fixtures/scope-cascade/plans/whole-codebase-review.md",
        "evals/fixtures/scope-cascade/plans/performance-windows.md"
      ]
    },
    {
      "id": 14,
      "prompt": "Continue $next-goal after its dev-scope choice response. I select the recommended Launch Path boundary and still want both delivery variants.",
      "expected_output": "Exactly two text fenced blocks and no prose before, between, or after them. The compact prompts have the same confirmed contract for Storage Baseline followed by Renderer Rollout, pair each semantic result with its source, use goals/dev/<slug>.md as durable state, complete after Launch Path rollout, explicitly exclude Compliance Sweep, and require $progress recovery on every resume. Their contracts are textually identical except for Delivery, and the response does not repeat the choice set.",
      "files": [
        "evals/fixtures/checkpoint-chain/AGENTS.md",
        "evals/fixtures/checkpoint-chain/ROADMAP_DEV.md",
        "evals/fixtures/checkpoint-chain/plans/dev/storage-baseline.md",
        "evals/fixtures/checkpoint-chain/plans/dev/renderer-rollout.md",
        "evals/fixtures/checkpoint-chain/plans/dev/compliance-sweep.md"
      ]
    },
    {
      "id": 15,
      "prompt": "Continue $next-goal from the one-option scope response. I confirm Workspace Import and authorize the goal-running agent to decide the unresolved conflict and compatibility policies using its best judgment within that outcome.",
      "expected_output": "Exactly one unlabeled text fenced block and no prose before or after it. The prompt contains the confirmed closed Workspace Import outcome and its cited source. Its Authority field explicitly authorizes the goal-running agent to resolve remaining decisions within that outcome using best judgment while requiring user direction for scope expansion or external actions not covered by the contract and Delivery. It does not repeat the scope choice or ask the user to repeat confirmation or delegation.",
      "files": [
        "evals/fixtures/insufficient-planning/AGENTS.md",
        "evals/fixtures/insufficient-planning/ROADMAP.md",
        "evals/fixtures/insufficient-planning/plans/workspace-import.md"
      ]
    },
    {
      "id": 16,
      "prompt": "Continue $next-goal from the one-option scope response. I confirm Workspace Import, but do not assume answers to its unresolved product decisions.",
      "expected_output": "The agent accepts the explicit scope confirmation, identifies the conflict and compatibility policies as the remaining readiness gaps, emits no fenced goal prompt, and asks the user to choose between bounded best-judgment delegation and planning repair with $interview followed by $progress. It does not repeat the scope-choice question or mutate planning.",
      "files": [
        "evals/fixtures/insufficient-planning/AGENTS.md",
        "evals/fixtures/insufficient-planning/ROADMAP.md",
        "evals/fixtures/insufficient-planning/plans/workspace-import.md"
      ]
    },
    {
      "id": 17,
      "prompt": "Continue $next-goal from the Publication Foundation scope choices. Instead of the recommendation, I choose an adjusted substantial boundary through Local Preview: include Canonical Artifacts, Evaluation Data Plane, and Local Preview, then stop before Publication Viewer Scaling.",
      "expected_output": "Exactly one unlabeled text fenced block and no prose before or after it. The agent preserves the user's confirmed non-recommended boundary instead of restoring the full Publication Foundation recommendation. The contract includes exactly Canonical Artifacts, Evaluation Data Plane, and Local Preview with their sources, names Publication Viewer Scaling as the immediate exclusion, and applies the readiness and delivery rules normally. It does not repeat the choices or ask for redundant confirmation.",
      "files": [
        "evals/fixtures/scope-cascade/AGENTS.md",
        "evals/fixtures/scope-cascade/ROADMAP.md",
        "evals/fixtures/scope-cascade/plans/canonical-artifacts.md",
        "evals/fixtures/scope-cascade/plans/evaluation-data-plane.md",
        "evals/fixtures/scope-cascade/plans/local-preview.md",
        "evals/fixtures/scope-cascade/plans/publication-viewer-scaling.md"
      ]
    },
    {
      "id": 18,
      "prompt": "Use $next-goal for Publication Foundation through Local Preview: include Canonical Artifacts, Evaluation Data Plane, and Local Preview, and stop before Publication Viewer Scaling. Return the recommended prompt.",
      "expected_output": "Exactly one copy-ready text fenced prompt for the initial named boundary, with no scope-confirmation pause. It preserves all three included results and sources, explicitly excludes Publication Viewer Scaling, passes readiness, and makes no mutation.",
      "files": [
        "evals/fixtures/scope-cascade/AGENTS.md",
        "evals/fixtures/scope-cascade/ROADMAP.md",
        "evals/fixtures/scope-cascade/plans/canonical-artifacts.md",
        "evals/fixtures/scope-cascade/plans/evaluation-data-plane.md",
        "evals/fixtures/scope-cascade/plans/local-preview.md",
        "evals/fixtures/scope-cascade/plans/publication-viewer-scaling.md",
        "evals/fixtures/scope-cascade/plans/whole-codebase-review.md",
        "evals/fixtures/scope-cascade/plans/performance-windows.md"
      ]
    },
    {
      "id": 19,
      "prompt": "Use $next-goal to show the substantial scope choices in this repository. Recommend one, but wait for me to choose before generating a goal prompt.",
      "expected_output": "The agent honors the explicit preview-only request: present materially distinct boundaries, recommend Publication Foundation, ask for selection, and emit no goal prompt or mutation. Delegation defaults do not override the requested pause.",
      "files": [
        "evals/fixtures/scope-cascade/AGENTS.md",
        "evals/fixtures/scope-cascade/ROADMAP.md",
        "evals/fixtures/scope-cascade/plans/canonical-artifacts.md",
        "evals/fixtures/scope-cascade/plans/evaluation-data-plane.md",
        "evals/fixtures/scope-cascade/plans/local-preview.md",
        "evals/fixtures/scope-cascade/plans/publication-viewer-scaling.md",
        "evals/fixtures/scope-cascade/plans/whole-codebase-review.md",
        "evals/fixtures/scope-cascade/plans/performance-windows.md"
      ]
    }
  ]
}

# Fixture Instructions

Use `ROADMAP_DEV.md` as this worktree's isolated planning index. The Storage
Baseline and Renderer Rollout plans form the settled Launch Path outcome. The
Compliance Sweep is the next independent program and needs separate approval.

# Compliance Sweep

## Outcome

Run an independent compliance program over the completed Launch Path.

## Current state

This is valuable and unblocked after rollout, but belongs to a separate goal.

## Next action

Wait for explicit authorization.

# Renderer Rollout

## Outcome

The renderer consumes the storage baseline and completes the Launch Path.

## Current state

Rollout behavior is settled and depends on the storage baseline.

## Next action

Implement and validate rollout after storage lands.

# Storage Baseline

## Outcome

The launch data has a validated durable storage baseline.

## Current state

The design and acceptance conditions are settled.

## Next action

Implement and validate storage behavior.

# Development Roadmap

## Current

[Storage baseline](plans/dev/storage-baseline.md)

## Plans

1. [Renderer rollout](plans/dev/renderer-rollout.md)
2. [Compliance sweep](plans/dev/compliance-sweep.md)

## Tasks

_None._

# Fixture Instructions

Treat `ROADMAP.md` and its linked plan as the source of truth. Workspace import
is a substantial closed outcome, but the plan intentionally leaves
consequential product policies unresolved. Do not infer the user's preferences.

# Workspace Import

## Outcome

Users can safely import an existing workspace archive into the current
workspace.

## Current state

The repository has no import implementation. The plan does not decide whether
conflicting records should replace existing data, merge with it, or stop the
import. It also leaves the supported archive versions and compatibility policy
unsettled. These choices affect data-loss risk and user-visible behavior.

## Next action

Settle the conflict and compatibility policies before implementation.

# Roadmap

## Current

[Workspace import](plans/workspace-import.md)

## Plans

_None._

## Tasks

_None._

# Fixture Instructions

Treat `ROADMAP.md` and its linked plan as the source of truth. The user may
explicitly settle and commit the foundation plan before goal selection.

# Foundation

Readiness: draft

## Outcome

Complete the settled foundation implementation and its verification boundary.

## Current state

Requirements and acceptance conditions are complete. Implementation may begin
after the user-authorized readiness update.

## Next action

After readiness is settled, implement and verify the complete foundation.

# Roadmap

## Current

[Foundation](plans/foundation.md)

## Plans

_None._

## Tasks

_None._

# Fixture Instructions

Treat `ROADMAP.md` and its linked plan files as the source of truth for project
order and implementation detail. Keep them accurate as work completes.

The four Publication Foundation plans form one settled phase. The integrated
whole-codebase review belongs to the next phase and requires a separate goal.

# Canonical Artifacts

## Outcome

Publication artifacts have one canonical, validated representation consumed by
the remaining foundation work.

## Current state

The representation and migration rules are settled, but implementation has not
started.

## Next action

Implement and validate the canonical representation.

# Evaluation Data Plane

## Outcome

Evaluation results flow through the canonical artifacts and remain inspectable
by publication tooling.

## Current state

Interfaces and acceptance conditions are settled in this plan.

## Next action

Implement the data flow after canonical artifacts land.

# Local Preview

## Outcome

Authors can preview the canonical publication and evaluation output locally.

## Current state

The preview contract is settled and depends on the first two foundation plans.

## Next action

Build the preview path and validate representative output.

# Official Performance and Windows Evidence

## Outcome

Collect official cross-platform performance evidence for a later release gate.

## Current state

This program follows the integrated review and is outside the Publication
Foundation phase.

## Next action

Do not begin before the review and separate authorization.

# Publication Viewer Scaling

## Outcome

The publication viewer handles the settled large-output scenarios and closes
the Publication Foundation phase.

## Current state

Scaling targets and validation scenarios are settled.

## Next action

Implement the scaling work after local preview is complete.

# Integrated Whole-Codebase Review

## Outcome

Review the completed foundation as one integrated system and route findings
into later remediation work.

## Current state

This is the first plan in the next phase. It is valuable and unblocked once the
Publication Foundation finishes, but it requires a separate goal.

## Next action

Wait for separate authorization after the foundation goal completes.

# Roadmap

## Current

[Canonical artifacts](plans/canonical-artifacts.md)

## Plans

1. [Evaluation data plane](plans/evaluation-data-plane.md)
2. [Local preview](plans/local-preview.md)
3. [Publication viewer scaling](plans/publication-viewer-scaling.md)
4. [Integrated whole-codebase review](plans/whole-codebase-review.md)
5. [Official performance and Windows evidence](plans/performance-windows.md)

## Tasks

_None._

# Delivery Variants

Read this file only after a scope has been selected under the entry point's scope rules, `/goal` is warranted for that scope, and the readiness gate has passed.

## Output Order

By default, return exactly one unlabeled `text` fenced block containing only the body to enter after `/goal`. Do not repeat the earlier scope choices or put a boundary explanation, delivery rationale, prerequisite-mutation recap, validation or review status, copy instruction, label, alternate offer, or any other prose before or after the fence. The selected boundary is expressed by the contract, and the evidence-based delivery recommendation is expressed by its `Delivery` field.

When the user explicitly requests one named delivery variant, return exactly one unlabeled `text` fenced block for that variant even if it differs from the evidence-based recommendation. Do not add an explanation of the discrepancy; the user explicitly chose the emitted delivery mechanics.

When the user explicitly asks for both variants, return exactly two `text` fenced blocks and no other prose. Identify each variant through its `Delivery` field:

- **PR delivery** — require sequential PR creation, review, and merge.
- **No PR** — require completion without PR creation.

Assume each new session has none of this conversation. Emit a closed routing envelope whose only job is to carry scope, recovery, and delivery into that session. Let cited repository documents carry requirements, design detail, acceptance criteria, commands, and checklists.

Use as few words as the boundary permits and cap each fenced prompt at 220 words by default. Exceed that cap only when more included results or explicit exclusions are required to keep the boundary closed and unambiguous. Emit exactly one structured contract and keep the complete delivery lifecycle inside its `Delivery` field.

Use this field order:

```text
Goal contract
- Outcome:
- Goal state:
- Included results and sources (semantic results define scope; paths supply detail):
  - <semantic result> — <source path or paths>
- Complete when:
- Excluded:
- Authority: <use the applicable exact authority form below>
- Resume: Initialize this contract with $progress goal mode before work; recover it before every resume, continuation, compaction, or handoff; stop if recovery fails.
- Delivery: <variant-specific lifecycle below>
```

Keep the envelope tight:

- Write `Outcome` as one sentence.
- Name each included result with a short semantic label and the fewest authoritative source paths. Let the sources carry implementation and acceptance detail; applicable instructions and `$progress` supply routing documents.
- Default `Complete when` to: `Every included result achieves its cited outcome and applicable completion criteria within its named semantic boundary; repository-required validation and review pass; planning is truthful; Delivery finishes.` Add only a missing cross-cutting terminal condition needed for this goal.
- Populate `Excluded` from exactly two inputs: the immediate next out-of-scope milestone and exclusions stated directly by the user. Keep every later, unrelated, or merely plan-documented item implicit under `Authority`.
- Let applicable `AGENTS.md`, `$progress`, and the delivery skills supply standard execution behavior. Add execution text only for a missing permission or invariant required in the fresh session.

When both variants are requested, keep every contract field except `Delivery` textually identical.

## Authority

When planning passed the readiness gate without delegation, use:

`- Authority: Execute only included results and necessary supporting work; record anything else and ask before scope expansion or external actions not covered by this contract and Delivery.`

When the user delegated unresolved decisions at the readiness gate, use:

`- Authority: Execute only included results and necessary supporting work; resolve remaining decisions within that closed outcome using best judgment; record anything else and ask before scope expansion or external actions not covered by this contract and Delivery.`

## Delivery Recommendation

Treat PR creation as the point at which a completed change slice is sent for CodeRabbit review. Estimate the expected review surface from repository evidence, including the likely diff and breadth of affected behavior or contracts; size the implementation change, not the effort required to discover or produce it.

- Recommend **PR delivery** when the goal should produce one or more substantial, cohesive CodeRabbit review slices on its own. Review them during the goal so later work does not make a slice oversized.
- Recommend **No PR** when the goal's expected change is too small for a useful standalone CodeRabbit review slice. Preserve its coherent commits for aggregation with future related changes into a later PR and request CodeRabbit review then.

When the evidence is close, choose the option that yields the fewest substantial, cohesive review slices without allowing one to become oversized. The recommendation decides when CodeRabbit reviews the changes, not whether it eventually reviews them.

## PR Delivery

Use this `Delivery` field:

`- Delivery: PR delivery — use $progress's PR lifecycle and the fewest sequential reviewable PRs; finish each through $create-pr and $address-pr-feedback before starting the next, including the final implementation slice.`

## No PR

Use this `Delivery` field:

`- Delivery: No PR — use $progress's no-PR lifecycle, preserve coherent commits for later reviewed aggregation, and reserve PR creation and PR-only feedback workflows for that later delivery.`

## Final Check

Verify that the recommendation follows the expected review-surface rule and every emitted envelope:

- is actionable without the conversation;
- names a durable state path and invokes `$progress` for initialization, recovery, and fail-closed behavior;
- uses short semantic result labels while cited documents carry the detail;
- includes only boundary-relevant exclusions;
- states each invariant once;
- keeps the complete delivery lifecycle inside the persisted `Delivery` field;
- stays within 220 words unless boundary clarity requires more.

When both variants are emitted, also verify that their boundaries and contract fields match except for `Delivery`.

Finally verify that the complete response consists only of the requested `text` fenced prompt block or blocks.

---
name: next-goal
description: "Select an evidence-backed substantial goal scope using user direction or delegated judgment, resolve material scope choices, then emit a copy-ready fresh-session routing envelope. Explicit invocation only."
---

# 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.

Each option must state only the decision-relevant boundary:

- the semantic outcome;
- the included results, summarized rather than expanded into a goal contract;
- the immediate next result or milestone it stops before; and
- whether it is ready or has a specific planning gap that would require delegation or repair after selection.

When presenting choices, mark exactly one option as `(Recommended)` and explain why in one compact sentence. Prefer the largest useful outcome that a persistent goal-running agent can pursue autonomously, while weighing outcome value, coherence, planning readiness, blocker risk, and separation from later milestones. The scope recommendation is distinct from the later delivery recommendation.

When a choice response is needed, use a structured choice control when it can faithfully represent the supported options; otherwise use a numbered list. Ask the user to choose by number or name or to propose an adjusted boundary. Emit no fenced goal prompt. If no substantial candidate remains that is implementable now or could pass readiness through bounded delegation or planning repair, say that `/goal` is not warranted and stop instead of manufacturing an option. Keep substantial candidates with planning gaps in the choice set so the readiness gate can handle them after selection; do not offer work that still depends on external authorization or an unresolved external blocker.

Stop here only when awaiting an unresolved scope choice or honoring a request to present options first. Otherwise continue in the same turn. A delivery variant alone does not select a scope when materially different boundaries remain unresolved.

## 3. Finalize the Selected Goal Boundary

Revalidate the selected scope against the current repository state before finalizing it. If material repository changes invalidate the boundary, resolve the scope again using applicable delegated authority; ask when that authority cannot resolve the changed choice. Otherwise preserve the user's chosen boundary even when it differs from the recommendation.

Apply these boundary rules both when framing options and when finalizing the selected choice. Naturally connected work may be absorbed into an option, and a selected adjusted boundary may be refined only enough to make it semantically closed. A goal may span subsystems and multiple coherent commits when they lead to one meaningful project state.

When both delivery variants are requested, keep their selected boundary identical. In the PR variant, treat PRs as delivery checkpoints within the large goal rather than separate `/goal` boundaries.

The selected boundary must:

- be materially larger than work suited to one ordinary interactive turn;
- reach a concrete, demonstrable project or user outcome rather than only a prerequisite or internal seam;
- contain enough settled or explicitly delegated work to benefit from persistent execution across multiple checkpoints;
- stop at a consequential unresolved decision the readiness gate does not settle or delegate, external authorization, blocker, or materially unrelated next milestone—not merely at the next plan heading or reviewable slice.

Do not expand a small selected scope beyond applicable user direction or delegated selection authority. If the selected choice is not substantial enough for `/goal`, explain that and return to scope choice rather than silently replacing it. A substantial selected scope whose planning is incomplete proceeds to the gate.

Before the readiness gate, reduce the selected scope to this closed routing envelope:

- **Outcome** — the semantic project or user result in one sentence.
- **Goal state** — one concrete durable path: `goals/<stable-slug>.md` for ordinary work or `goals/<scope>/<stable-slug>.md` for an isolated worktree planning scope.
- **Included results and sources** — every authorized result as a short, stable semantic label paired with the few authoritative documents that supply its implementation and acceptance detail. Labels define membership; paths and queue positions do not.
- **Completion** — one compact predicate requiring each named result to achieve its cited outcome and any applicable completion criteria, plus only cross-cutting validation, review, freshness, and delivery conditions not already carried by those sources.
- **Excluded work** — exactly the immediate next out-of-scope milestone plus exclusions stated directly by the user. Authority supplies the complete boundary for every later, unrelated, or merely plan-documented item.
- **Authority** — allow only the smallest bounded work necessary for an included result. When the readiness gate passed by delegation, also authorize the goal-running agent to resolve remaining decisions within the closed outcome using its best judgment. Record anything outside the boundary for later and require explicit user direction for expansion or external actions not covered by the selected contract and delivery lifecycle.
- **Resume invariant** — at every resumed turn, automatic continuation,
  compaction recovery, or handoff, invoke `$progress` in goal mode and recover
  the named goal state before selecting or starting more work.
- **Delivery** — the selected lifecycle and its skill routing, kept inside the contract so recovery preserves it.

Record the exact planning gap when evidence cannot yet support a field; do not invent closure. Boundary finalization is complete when the selected scope, its provisional envelope, and every unsupported field are ready for the readiness gate.

Treat goal membership as closed. Advancing a roadmap, changing `Current`, creating a plan, opening a branch or PR, or discovering review findings never adds work to the goal. Project planning state describes what the project should do next; the goal contract alone describes what this run is authorized to do.

## 4. Pass the Readiness Gate

Before emitting a goal prompt, verify that the evidence supports a closed outcome, semantic included results and authoritative sources, a completion predicate, and enough settled direction for autonomous implementation. Reversible implementer-owned choices may remain open. Consequential user-owned decisions require explicit delegation or planning repair.

When the outcome is closed but consequential decisions remain, first check
whether the user already delegated those decisions or selected planning repair.
Apply that choice within its stated scope. Otherwise explain the specific
planning gaps and ask them to choose:

1. authorize the goal-running agent to resolve the remaining decisions within the closed outcome using its best judgment; or
2. repair planning first with `$interview` followed by `$progress`, then rerun goal selection.

Emit no goal prompt until an applicable user choice resolves the gate.
Delegation passes the gate only for decisions inside the supported outcome; it
never adds results, expands scope, or grants external authority. Record that
delegation in the generated contract's `Authority` field so the goal-running
agent does not ask again merely because the cited plans left those decisions open.

If the user chooses planning repair, treat that answer as an explicit request for the separate mutating phase: use `$interview` to settle consequential decisions, then `$progress` to update the authoritative planning documents. Restart current-state resolution from the resulting repository state and keep the renewed selection phase read-only. Planning repair does not erase an already selected scope; revalidate and retain it unless the new evidence materially changes its boundary, in which case resolve the scope again under step 2. When no closed outcome can be supported, explain why delegation is unavailable and ask to repair planning before goal selection.

The gate is complete only when planning is sufficient or the user has explicitly delegated the remaining decisions within a supported closed outcome. Finalize every routing-envelope field after it passes.

## 5. Route the Result

- When `/goal` is **not warranted**, give the evidence-based reason and omit the prompt. Do not read the delivery-variant instructions.
- When the scope **remains unresolved** or the user requested options first, return only the compact choice set, recommendation, and selection question from step 2. Do not read the delivery-variant instructions or emit a goal prompt.
- Once the scope is selected, the evidence establishes that `/goal` **is warranted**, and the readiness gate passes, read and follow [prompts/delivery-variants.md](prompts/delivery-variants.md).
- By default, return only the recommended prompt as one unlabeled `text` fenced block. Put only the body to enter after `/goal` inside it, with no prose before or after the fence.
- Honor an explicit request for one named delivery variant even when it differs from the evidence-based recommendation; identify the emitted variant through its `Delivery` field.
- When the user explicitly requests both variants, return only the two `text` fenced prompt blocks, identify the variant inside each prompt's `Delivery` field, put the same closed scope contract inside both prompt bodies, and vary only the delivery mechanics and `Delivery` field.

Before responding, verify that the scope and selection phases made no repository write, goal change, git mutation, or external publication. When the request included prerequisite mutation, verify that it finished before scope discovery began, but do not add a separate recap when emitting a goal prompt after selection.