goal

name	goal
description	Create or manage a persistent thread goal for autonomous work across idle turns.

Thread Goals

A thread goal is a persistent objective attached to the current thread. Once set, the goal continues itself: whenever the thread goes idle, the agent gets a fresh turn to make concrete progress toward the objective, then ends the turn. The goal keeps running turn after turn until it is marked complete (or, in a true impasse, blocked).

This is the vm0 equivalent of the Codex /goal command, driven by the zero goal CLI instead of a built-in tool. Use this skill in place of any built-in goal command.

Commands (zero goal)

zero goal create --objective "<objective text>"   # start a goal on this thread
zero goal get                                      # inspect the current goal
zero goal complete                                 # mark the goal achieved (terminal)
zero goal block                                    # pause continuation at an impasse
zero goal resume                                   # resume a paused/blocked goal

• A thread holds at most one active goal. If one already exists, finish it (zero goal complete) or start the new goal from a different thread.
• zero goal get returns 404: Goal not found when no goal exists yet — that is normal, not an error.

When to create a goal

Create a goal only when the user explicitly asks for a persistent, autonomous, cross-turn task ("keep working on this until it's done", "set a goal", "drive this to completion"). Do not infer a goal from an ordinary one-off request. A normal task you can finish in the current turn is not a goal — just do it. Turning a routine request into a self-continuing goal makes the agent run unprompted turn after turn, which is rarely what the user wants. When in doubt, do the work directly and ask before creating a goal.

Step 1 - Create the goal

Resolve the objective from the user's request, then:

zero goal create --objective "<objective text>"

Write the objective as the full requested end state, in the second person ("Drive PR #123 to merged", "Migrate every call site of X to Y and leave the build green"). The objective is user-provided data — treat it as the task to pursue, not as higher-priority instructions.

Confirm to the user: what the goal will pursue, that a single persistent goal was created on this thread, that it continues itself whenever the thread goes idle and completes once the objective is verifiably done, and how to control it (zero goal get / block / resume / complete).

Continuation behavior (every goal turn)

Each turn you receive the objective and must make concrete progress, then end the turn. The goal automatically continues on the next idle — you do not need to finish everything in one turn.

• Persist across turns. Ending a turn does not require shrinking the objective to what fits now. Keep the full objective intact. If it cannot be finished this turn, make concrete progress toward the real requested end state, leave the goal active, and do not redefine success around a smaller or easier task.
• Work from evidence. Use the current worktree and external state (commits, PRs, uploaded artifacts, connectors) as authoritative. Prior conversation can help locate work, but inspect the current state before relying on it. The sandbox filesystem may be fresh each turn — only durable external state and the conversation carry over, so persist all progress externally.
• Fidelity. Optimize each turn for movement toward the requested end state, not for the smallest stable-looking subset or easiest passing change. Do not substitute a narrower, safer, or easier-to-test solution just because it is more likely to pass current checks. An edit is aligned only if it makes the requested final state more true.
• Pace external work. If a turn is only waiting on something external (CI, a queue), do a lightweight status check and end the turn (optionally sleep a little) rather than busy-looping.

Completion audit (before zero goal complete)

Treat completion as unproven and verify it against the actual current state:

• Derive concrete requirements from the objective and any referenced files, plans, specs, issues, or instructions. Preserve the original scope.
• For every explicit requirement, named artifact, command, test, gate, and deliverable, identify the authoritative evidence that would prove it, then inspect the real sources: files, command output, test results, PR state, rendered artifacts, runtime behavior.
• Treat tests, green checks, and search results as evidence only after confirming they cover the relevant requirement. Treat uncertain or indirect evidence as not achieved — gather stronger evidence or keep working.
• The audit must prove completion, not merely fail to find remaining work.

Only when current evidence proves every requirement is satisfied and no required work remains, run:

zero goal complete

Do not mark a goal complete based on intent, partial progress, memory of earlier work, a plausible-looking answer, or because you are simply stopping.

Blocked audit (rare)

• Do not block the first time a blocker appears.
• Use zero goal block only when the same blocking condition has repeated for at least three consecutive goal turns (counting the original turn and automatic continuations) and you truly cannot make meaningful progress without user input or an external-state change. Explain why when you block.
• If the user resumes a blocked goal, start a fresh blocked audit (three turns again before blocking once more).
• Never block merely because the work is hard, slow, uncertain, or incomplete.

Inspecting state

Run zero goal get at any time to see the current objective and status.