# Goal > Use when the user invokes /goal, asks for goal mode, designs an agent loop, or starts long-horizon autonomous work that should be clarified into a concrete, verifiable objective before execution. - **Type:** Skill - **Install:** `agentstack add skill-infinite-labs-ai-infinite-skills-goal` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [Infinite-Labs-AI](https://agentstack.voostack.com/s/infinite-labs-ai) - **Installs:** 0 - **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [Infinite-Labs-AI](https://github.com/Infinite-Labs-AI) - **Source:** https://github.com/Infinite-Labs-AI/infinite-skills/tree/main/skills/goal - **Website:** https://infinite.fast/agents/ ## Install ```sh agentstack add skill-infinite-labs-ai-infinite-skills-goal ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # 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=_\_ 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. > **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: ```text 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](https://github.com/Infinite-Labs-AI) - **Source:** [Infinite-Labs-AI/infinite-skills](https://github.com/Infinite-Labs-AI/infinite-skills) - **License:** MIT - **Homepage:** https://infinite.fast/agents/ Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-infinite-labs-ai-infinite-skills-goal - Seller: https://agentstack.voostack.com/s/infinite-labs-ai - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.