> ## Documentation Index
> Fetch the complete documentation index at: https://docs.qoder.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Goal-driven

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

<CardGroup cols={2}>
  <Card title="Goal-driven autonomous execution" icon="bullseye">
    * 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.
  </Card>

  <Card title="Flexible process control" icon="sliders">
    * 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.
  </Card>
</CardGroup>

## 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

<Steps>
  <Step title="Enable Goal mode">
    Click the "**+**" button on the input box and turn on the **Goal** toggle, or type `/goal` in the input box.
  </Step>

  <Step title="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%`
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

<Note>
  Goal-Driven Execution runs for up to **10 turns** by default and stops automatically once the limit is reached. You can raise the maximum turn budget from **Settings → Integrations → Built-in Capabilities → Goal-Driven Execution** to match the complexity of your task.
</Note>

## Goal vs. Spec

|                       | Goal-driven                                                 | Spec-driven                                                                         |
| --------------------- | ----------------------------------------------------------- | ----------------------------------------------------------------------------------- |
| **Positioning**       | Goal-oriented; the Agent plans the path autonomously        | Spec as the blueprint; implemented item by item per the plan                        |
| **Input**             | Describe the desired end state                              | A structured solution description                                                   |
| **Execution**         | The Agent iterates on its own and judges completeness       | Executes the Spec task list in order                                                |
| **Typical scenarios** | Raising test coverage, code refactoring, performance tuning | New 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](./scheduled-tasks) trigger.