Skip to content
OneviumDocs
On this page

Run a task toward an explicit goal

Use /goal with a measurable completion condition, inspect progress, and keep long work within its agreed scope.

Keep a conversation working toward a condition#

/goal is a native Claude Code command for setting a completion condition on the current task. Onevium displays the goal information returned by the runtime. Simply writing the word “goal” in a prompt does not create one automatically.

Goal governs continued work on the current task. Use scheduled tasks for work triggered at a time or on a recurring schedule; they are separate features.

Find the Goal command#

Type / in the target conversation's composer and check for goal in the command list. Onevium bases this entry on commands reported by its running SDK, not the version of a separate CLI you installed in a terminal.

If goal is missing, first confirm model connectivity and reopen the command list. If it remains missing, inspect the app version and command response. A normal reply saying “I will continue” is not proof that Goal is enabled, and installing an unrelated skill with the same name is not a solution.

Define three kinds of conditions before starting:

ConditionA useful example
OutcomeFind the specified flow's entry point, handling logic, error branches, and tests
EvidenceCite real files for each finding and explicitly record missing tests
BoundariesDo not edit files or start services; report any required repository you cannot access

“Make it perfect” has no clear finish. Writing “no more than 10 minutes” in a prompt does not configure an enforced system time or spending limit.

Set a verifiable goal#

Select the correct project, provider, model, and permissions. After confirming goal support, send this whole example as one message, with /goal at the beginning:

text
/goal Investigate this project's member-invitation flow and produce an evidence-backed checklist.
Completion conditions:
1. Find the interface entry and server handling; cite real files for both.
2. Explain permission checks and invitation expiry, explicitly noting any missing implementation.
3. List existing related tests. If none exist, record that gap instead of claiming tests pass.
Read-only investigation: do not edit files, install dependencies, or start services.
If a required repository is inaccessible, report the specific blocker instead of repeating the same failed attempt.

The example investigates code that actually exists in your project. If it has no member-invitation feature, choose an existing flow instead.

ActionSend separately
Inspect the current goal/goal
Set a goal/goal followed by explicit completion conditions
Clear the current goal/goal clear

Send status and clear commands without unrelated task text appended to them, which can change their meaning. Follow the command's response in your conversation.

Read progress and verify completion#

Once the runtime reports an active goal, an indicator above the composer shows its condition, iteration count, elapsed time, and latest evaluation reason. State belongs to the conversation; in split view, check which column you are inspecting.

Look for new evidence in each iteration: a relevant file inspected, an error branch located, or a missing test confirmed. Repetition of the same failure is a reason to address the blocker first.

When completion is reported, check every condition against its evidence. Tests that were not run must remain “not run.” File references do not substitute for execution results. Neither the indicator nor the iteration count proves completion.

Interrupt, clear, and resume work#

  • Interrupt only the current turn: use the composer's stop button and wait for generation to stop. Do not assume that interrupting also clears the goal.
  • End work on this goal: after the current turn stops, send /goal clear separately and inspect the returned state before setting another goal.
  • Handle an approval: inspect the requested action. Goal does not expand your authorized file, command, or external-action scope.
  • After reopening the app: query the current goal state before continuing or setting it again. An existing conversation does not mean its goal has resumed.
  • A development service is still running: stopping a conversation or clearing its goal does not stop a managed service. Inspect and stop the specific service separately.

If /goal produces only a normal explanation, an unknown-command response, or no valid state feedback, investigate the running environment before claiming Goal is progressing automatically.

Next steps#

See scheduled runs for timed work, permissions for action boundaries, and projects and conversations for continuing work across conversations.