> Source: Onevium official documentation
> Article: Run a task toward an explicit goal
> Original URL: https://onevium.com/docs/goal-mode
> Language: English
> Updated: 2026-09-09
> Applies to: 1.1.22
> Feature status: Released

---

# 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](https://onevium.com/docs/scheduled-runs) for work triggered at a time or on a recurring schedule; they are separate features.

## Confirm support in the running version

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:

| Condition  | A useful example                                                                      |
| ---------- | ------------------------------------------------------------------------------------- |
| Outcome    | Find the specified flow's entry point, handling logic, error branches, and tests      |
| Evidence   | Cite real files for each finding and explicitly record missing tests                  |
| Boundaries | Do 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.

| Action                   | Send 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 response from the version you are actually running.

## 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:** the 1.1.22 indicator uses in-memory state. The conversation's continued existence does not prove its goal was restored. Query the current state before continuing or setting it again.
- **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](https://onevium.com/docs/scheduled-runs) for timed work, [permissions](https://onevium.com/docs/permissions) for action boundaries, and [projects and conversations](https://onevium.com/docs/projects-and-sessions) for continuing work across conversations.