goal

Goal Mode (/goal)

/goal is for durable autonomous work: the goal text becomes the exit criteria the agent is re-checked against after every turn, so it keeps working until the goal holds. So the rule is simple — the agent must know what "done" means, and how it will be proven, before it starts. The preflight below makes sure of that: a fuzzy goal gets a real discovery conversation first (so you shape it together), then a tight structured confirmation; a genuinely crisp goal can fast-path straight to the contract. Never start on "I'll know it when I see it."

The bar: a runnable, self-evident done-check

A goal is ready when its done-condition is observable, ideally numeric, and provable from what the agent itself surfaces — not asserted. The turn-by-turn completion check judges the agent's own output and does not run your tools, so write the done-check as something the agent demonstrates in the transcript (show the passing test / the metric / the diff), never "trust me, it passes." Pick the strongest available check, in this order:

1. Rules / commands — npm test exits 0, build succeeds, lint clean, a benchmark number. (Best.)
2. Visual — a screenshot or visual diff, for UI. (Specs/checklists are the real criterion — never a raw image alone.)
3. LLM judgement — last resort; not robust, high latency.

Good goals carry a number: "Reduce build+deploy time 30%." · "Migrate this feature TS→Rust at 100% test parity." · "Get production LCP < 2.5s." If you can't yet name a runnable check, that is the ONE thing to resolve before starting — propose a check and confirm it; don't start on a feeling.

Preflight: discovery → decide → start

A goal should be bigger than one prompt but smaller than an open-ended backlog. If the request is a loose list of unrelated work, it's not a goal — ask to split it; do not interview.

1. Classify intent. Only answering a question about goal mode → answer normally. Starting autonomous work → continue.
2. Read local context first. Inspect the relevant files / failing tests / logs / docs / plan BEFORE asking anything — most fields are inferable straight from the repo.
3. Discovery — a real, CONVERSATIONAL back-and-forth (do this BEFORE the structured questions). Reflect back what you understand, then have an open exchange — typically 3–6 short rounds — to genuinely understand: the why behind it, what "great" looks like, the approach/options and their trade-offs, the constraints, and the landmines/risks. Go one thread at a time, build on each answer, and listen more than you talk — plain open questions, NOT multiple-choice. Don't rush to the structured gate; keep exploring until you could explain the goal back better than the user first did. Stop once it's genuinely well-understood (or sooner if the user signals they're ready). (Per OpenAI's own guidance: brainstorm the project first, then set the goal.)
4. Draft the contract stub — one line, and the forcing artifact: you literally cannot fill it without an exit criterion. Emit it from the discovery + context:

   Outcome: <one concrete end state> · Done when: <runnable check + expected result> · Guard: <only the must-not-regress / destructive limits> · Inferred (correct me): start=<files/URLs>, between-tries=<iteration policy>, refresh=<signals>, track=<commits + progress log>, on-blocked=<what to report + what would unlock>

5. Lock the MANDATORY fields with STRUCTURED questions. Now switch from open chat to decisions: just three things must be user-confirmed if still unresolved — Outcome, the Done-check, and any destructive/irreversible constraint (paid deps, migrations, force-push, prod deploy, real spend). Ask these as at most 3 multiple-choice questions in ONE batch (multiple-choice because these are decisions, not exploration). Everything else — scope, starting point, iteration policy, context-refresh, anti-cheat, tracking, finalization — infer and put in the stub's "Inferred" line for the user to redline; don't ask. Never run a second batch unless an answer revealed a contradiction; tempted to ask a 4th → infer it and state it instead.
6. Start. Emit the final stub and invoke goal mode (create_goal where the runtime has it); begin immediately. Don't ask "should I proceed" unless the next action is destructive or externally side-effectful.