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 Outcome: \ · Done when: \ · > Guard: \ · Inferred (correct me): > start=\, between-tries=\, refresh=\, > track=\, on-blocked=\

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

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

> Fast path: if the request already makes the outcome AND a runnable check unambiguous (you could > state the success check in one sentence), skip discovery and the questions — emit the stub and > start. Discovery + rigor are for fuzzy goals, not clear ones.

The rhythm: listen (discovery) → decide (structured questions) → start. Discovery is open, human, and can take several rounds (≈3–6); the structured batch is tight (≤3, one shot). Spend the time understanding, not interrogating.

Design the loop, not just the first prompt

A durable run needs four live parts — goal, context, evaluation, action (gather context → act → verify → repeat). Name them in the stub:

• Iteration policy (between tries): how to choose the next move — default *"re-run the done-check,

attack the largest remaining gap."* This is what prevents rabbit-holing.

• Context refresh: start with the smallest useful context, then deliberately fetch more (CI,

logs, failure traces, analytics, review feedback) as the loop advances — don't dump it all up front.

• Guidance: point at where to start and what tools it may use. For ambitious goals, research/plan

first → write a plan file → have the goal reference it.

• Verify with the strongest signal, and don't self-grade: prefer rules over a model's opinion; for

big runs, use a fresh-context verification subagent so the agent doing the work isn't the one judging it.

• Budget ≠ done: hitting a turn/time/token budget is NOT completion — stop substantive work,

summarize progress + blockers, and name the next useful step. Add an explicit "or stop after N turns" clause when you want a hard ceiling.

Make progress measurable

If the goal is ambitious or has many paths, the loop must be able to know it's getting closer. Sometimes that's free (build time, test count); otherwise build or request the tool — an eval suite, or a visual-diff tool (which can evolve diff modes over the run). Guard against fake wins the headline check would miss — deleting/weakening tests, cropping a screenshot, inlining the design image to look "pixel perfect." Derive the anti-cheat clause mechanically from the done-check. For visual goals especially: use images as context, but define "done" via feature checklists / specs / design-system adherence — never make the raw image the sole exit criterion.

Create a realistic environment

Real progress needs the real stack: same flags, a similar database, deploy/test targets that mimic production. Watch for environments that diverge from prod (e.g. preview builds with paths disabled) — do manual prod-like deploys instead. Computer-use or a physical device gives the most accurate signal for performance/UI goals.

Track long runs

When a goal runs for hours or days (possibly on another machine), keep progress visible: commit at meaningful steps + push to a draft PR (great with preview deploys); keep a progress artifact (HTML dashboard / rendered graph / markdown); post milestones to Slack if asked; and use a short side-thread or a scheduled check-in to ask "where are we?" without disturbing the run.

Finalization

Reaching the target isn't the end — the run may have left dead ends and failed experiments behind. Before reporting done: run a review; reflect on the attempts and remove leftover/abandoned changes (matters most for optimization tasks). When reviewing, flag only gaps that affect correctness or the stated criteria — a reviewer told to "find gaps" always finds some, and chasing every one causes over-engineering. Mark complete ONLY when the done-check's evidence exists in the transcript; mark blocked only after the same blocker has held for ~3 turns with no alternative.

Full contract — expand ONLY for multi-day / multi-agent runs

The one-line stub is enough to start most goals. For long, multi-agent, or hand-off runs, expand it:

Goal: 
Done when: 
Scope: include  · exclude 
Iteration policy: 
Context refresh: re-check  every 
Constraints: 
Anti-cheat: 
Start at:  · Track via: 
On blocked: 
Final check: ; clean up dead ends before reporting done

Keep the live goal prompt short enough to remember across a long run, specific enough that another agent could decide whether it's complete.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: Infinite-Labs-AI
• Source: Infinite-Labs-AI/infinite-skills
• License: MIT
• Homepage: https://infinite.fast/agents/

Install and usage instructions live in the source repository linked above.