Goals

A goal keeps Kiki working toward an outcome across turns (one turn is a full pass of the agent handling one message). A prompt says what to do next; a goal says what must become true. Use /goal when there is a finish line but the next useful step depends on what the agent finds along the way — a batch of failing tests, or the root cause of a broken build.

Start a goal

Write the objective after /goal:

/goal Fix bugs listed in the issue tracker.

Kiki saves the objective, sends it as the next user message, and starts goal mode. After each turn, it checks the goal's four states: complete (done), blocked (cannot make progress), paused (interrupted by you or by an error), or still active.

Goals work best when the objective names the finish line and the evidence that proves it:

/goal Fix every bug labeled checkout-regression, add or update tests for each fix, and run the checkout test suite

Avoid goals that only name a broad direction:

/goal Find all bugs in this codebase.

That goal says nothing about what success looks like, what to inspect, or when to stop, so the agent may block immediately or work far longer than you expected.

When to use goals

1. Use goals for work with a clear finish line and verifiable evidence.

   /goal Fix every failing checkout test and run the checkout test suite successfully.

   Kiki can inspect test output, change files, rerun checks, and decide when the goal is complete.

2. Use goals when the task may need several turns of investigation and repair.

   /goal Find why the release build fails, fix the root cause, and verify the build passes.

   The goal describes the result, so the agent can adapt when the first clue is not the root cause.

3. Use goals for ordered work that should continue without another prompt.

   /goal Update the feature implementation, add docs, run tests, and summarize the changed files.

   This is useful when you already know the checks or artifacts that must exist before the work is done.

When not to use goals

1. Do not use goals for broad topics or open-ended discussions. /goal Greetings! is not a goal — the agent marks it complete immediately.

2. Do not use goals for tasks that are known to be impossible or unresolvable. If the agent judges a goal impossible, such as /goal Prove 1 + 1 = 3., it marks the goal blocked and explains why.

3. Do not use goals with ambiguous or complicated objectives. A goal with unclear boundaries, like /goal Create a videogame in a single HTML file., may complete — or may produce unexpected results after a long wait.

Manage the lifecycle

Use the same command surface to inspect or control the current goal:

Command	Action
/goal or /goal status	Show the current goal and its progress
/goal pause	Pause the active goal without deleting it
/goal resume	Resume a paused or blocked goal
/goal cancel	Remove the current goal
/goal replace <objective>	Replace the current goal with a new objective

A goal can stop in three ways:

• complete: the objective is done, Kiki clears the goal, and the agent summarizes how it completed the work
• paused: you paused it, interrupted the turn, resumed a session that had an active goal, or hit a model, provider, or runtime error
• blocked: Kiki needs input, cannot complete the goal as stated, or reached a budget limit. When the agent blocks a goal, it writes a short message explaining why.

Describe completion conditions in the objective. Goals have no hard budget by default. To cap a goal's turns, output tokens, or active time, set a budget manually in the web goal editor; limits written in chat do not configure a budget.

Pausing a goal stops its current goal-driven turn and automatic follow-up turns without deleting the objective. Background tasks already launched continue; their results wait for your next message. You can send ordinary messages while the goal is paused. Reopening a session after a restart pauses an active goal; a goal you already paused or cancelled stays stopped until you explicitly resume or create one.

A blocked goal does not cancel work it already started. When a task launched for it finishes, the result wakes the main agent to process that one completion; the goal itself stays blocked until you resume it. If you cancel the goal or its budget runs out, that result waits for your next message.

While a goal is active, each finished background task is delivered when the main agent is idle, including when another task is still running. That delivery does not wait for the other tasks, and it is not the goal's follow-up turn. The goal follows up on its own timing.

Manage goals in the web UI

The web UI shows the current goal above the composer. The Pause button remains visible beside an active goal, even when its details are collapsed. Select the goal title to expand its objective, completion criterion, follow-up timing, budget usage, and other controls; editing or loading those details does not disable Pause.

Budgets are optional and only you can set or clear them in this editor:

• Goal turns: cumulative turns for this goal, not the steps allowed within each turn.
• Output tokens: cumulative tokens generated by the model for this goal.
• Active time (seconds): cumulative time while the goal is active, including waits; paused time does not count.

Leave a budget blank to remove its limit, or use Clear limits to remove all three. Saving a budget does not reset usage or start another turn. Earlier saved budgets remain visible and can be cleared here.

Use Resume to continue a paused or blocked goal, or Cancel to remove it. If a budget blocks the goal, raise or clear that limit, save, then select Resume to start the next goal turn. Cancellation requires confirmation because it cannot be resumed afterwards.

Queue upcoming goals

When a goal finishes quickly and you already know what comes next, queue it instead of waiting:

/goal next Update the release notes after the tests pass

The agent does not see queued goals while the current one runs. Once the current goal completes, Kiki starts the first queued goal exactly as if you had typed /goal <objective>.

If no goal is active, /goal next <objective> starts that objective immediately. It behaves like /goal <objective> and shows a status message before the goal starts.

Manage upcoming goals interactively:

/goal next manage

In the manager, use ↑ / ↓ to browse, Space to select a goal for moving, ↑ / ↓ to reorder it, E to edit, D to delete, and Esc to cancel. When editing, use Shift-Enter or Ctrl-J to add a new line, and Enter to save.

If the current goal is paused, canceled, or blocked, Kiki does not start the next upcoming goal. When a goal blocks and upcoming goals exist, the TUI reminds you that they wait for completion.

Use goal mode carefully

Goal mode is useful for work that can be checked with files, tests, command output, generated artifacts, or a clear written report. It is less useful for a one-off edit or a question that only needs one answer.

Goal mode suits work you can check — files, tests, command output, generated artifacts, a written report. It is overkill for a one-off edit or a question with one answer.

Your permission mode decides whether tool calls wait for you. In manual mode, goal work pauses for approval on tool calls; for unattended work, pick a mode that matches the risk of the repository and the commands the agent will run.

In non-interactive prompt mode (kiki -p, which runs one prompt and exits), only goal creation is supported:

kiki -p "/goal Fix the failing checkout test"

Prompt mode communicates the result through its exit code (the status number a program returns to the caller, used by scripts to branch): 0 when the goal completes, 3 when it blocks, and 6 when it pauses. /goal next and other management commands are TUI controls.