Skip to main content
When you choose Goal mode in Quest, you only describe the outcome you want — Quest plans the path on its own, iterates continuously, and verifies the result. It’s a good fit for tasks that take multiple steps and where you’d rather “have a result delivered” than direct each step yourself.

​
Core capabilities

Goal-driven autonomous execution

  • You describe the goal; Quest breaks it down, plans the execution path, and keeps pushing forward without step-by-step instructions.
  • After each round, Quest evaluates the current progress and judges whether the goal is met. If not, it automatically moves on to the next iteration.

Flexible process control

  • Pause, edit the goal, or delete the task at any time during a run. Pausing preserves the full context and intermediate artifacts.
  • After you edit the goal, Quest continues against the new goal from the next round — it doesn’t reset existing progress.

​
Use cases

  • Long-running coding tasks: work with clear success criteria and a verification loop — e.g. raising test coverage, performance tuning, cross-file consistency fixes. Quest autonomously iterates and verifies until the goal is met.
  • Large-scale refactoring: code migrations, whole-repo framework upgrades, batch API replacements — tasks that can’t be planned out step by step in advance. Describe the desired end state as a Goal, and Quest plans the path and keeps iterating.

​
How to use

1

Enable Goal mode

Click the ”+” button on the input box and turn on the Goal toggle, or type /goal in the input box.
2

Describe the goal

Describe the end state you want in natural language. A goal should describe the expected result rather than specific steps — Quest plans the execution path itself.Example: /goal raise the project's test coverage above 80%
3

Autonomous execution

After you send the goal, Quest enters an autonomous execution loop:
  • A Goal progress card appears above the input box, showing the current goal and run status.
  • Quest evaluates progress after each round and continues automatically if the goal isn’t met, ending on its own once the goal is reached.
4

Manage the task during a run

The Goal progress card supports the following actions:
  • Edit: click the edit button in the top-right corner of the card to change the goal description. Editing during a run takes effect after the current round ends; editing while paused takes effect immediately.
  • Pause and resume: pausing preserves the full context and all intermediate artifacts; click resume to pick up from where it stopped.
  • Delete: deletes the current goal task and returns the conversation to a normal chat state. Files and messages already generated are not deleted.

​
Goal vs. Spec

Goal-drivenSpec-driven
PositioningGoal-oriented; the Agent plans the path autonomouslySpec as the blueprint; implemented item by item per the plan
InputDescribe the desired end stateA structured solution description
ExecutionThe Agent iterates on its own and judges completenessExecutes the Spec task list in order
Typical scenariosRaising test coverage, code refactoring, performance tuningNew feature development, building to a design, delivering well-defined requirements

​
Best practices

  • Describe a verifiable end state: a good goal is “test coverage reaches 80%,” not “write some tests.” Quest needs a clear completion criterion to judge whether the goal is met.
  • Include key constraints: if there’s something you don’t want changed, say so in the goal. For example, “optimize the internal implementation without modifying the public API.”
  • Keep the scope reasonable: an overly grand goal (such as “make the whole project better”) makes it hard for Quest to stay focused. Breaking it into specific, measurable sub-goals works better.
  • Combine with scheduled tasks: long-running Goal tasks are also well suited to running overnight. Use /schedule to set up a scheduled task trigger.