> ## Documentation Index > Fetch the complete documentation index at: https://agent.minimax.io/docs/llms.txt > Use this file to discover all available pages before exploring further. # Goal > Set a verifiable outcome for MiniMax Code and let it keep working until the goal is achieved or progress is blocked.
Goal lets you give MiniMax Code a clear destination with explicit acceptance criteria. MiniMax Code can repeatedly inspect results, make changes, and validate its work against that outcome. As long as the goal has not been achieved, it can determine the next step without waiting for you to say “continue” after every turn. Goal entry in the MiniMax Code menu ## What is Goal? Goal stops when the outcome has been achieved, progress is blocked, or you pause it. A regular prompt usually tells MiniMax Code what to do next: complete the current instruction, return the result, and wait for another request. A Goal tells MiniMax Code what the final outcome should be. While the goal remains active and the task can still move forward, MiniMax Code uses the result of each attempt to choose the next step. Give an instruction → Run it → Return the result → Wait for the next request Define the final outcome → Work → Check the result; continue with the next step if the goal has not been met, finish when it has, or report a blocker and wait. > A regular prompt focuses on the next action. Goal focuses on whether the intended end state is true. An actionable Goal should define the final outcome, the evidence that proves completion, and the conditions that must remain true while the work proceeds. Goal is not unrestricted background automation. It remains subject to the task scope, user control, available budget, and evidence that can actually be verified. ## How do I start a Goal? Goal appears in the command menu and the `+` menu next to the input box. If Goal is not available in either menu, update MiniMax Code to a version that supports it and confirm that the feature has been enabled in your environment. Type `/` in the input box and select **Goal** from the command menu, or select `+` next to the input box and choose **Goal**. Describe the final outcome, acceptance evidence, working boundaries, and stop conditions, then send it. After you send it, the Goal status appears above the input area. MiniMax Code continues working and checking results. You can edit, pause, resume, or clear the Goal at any time. Typing `/goal` directly in the input box does not enter Goal mode. Select **Goal** from the `/` command menu or the `+` menu first. ## When should I use Goal? **Goal works best when the destination is clear but the path requires iteration and judgment.** It keeps the outcome active so MiniMax Code can adjust the next step using evidence from tests, logs, benchmarks, or research. Common use cases include: * **Debugging:** Investigate an intermittent test failure, or reproduce a bug before fixing it. * **Engineering changes:** Complete dependency migrations or multi-stage refactors that require several rounds of work. * **Metric optimization:** Improve performance or iterate against a benchmark. * **Research deliverables:** Produce a report, reproducible result, or evidence audit. These tasks may be difficult to plan in full at the beginning, but they can still have clear completion criteria. For a one-line copy change, a simple error explanation, a short code review, or a change to one clearly identified file, a regular prompt is usually more direct. ## How do I write an effective Goal? The most important part is defining what completion means. The clearer the outcome, validation method, scope, and stop conditions are, the easier it is for MiniMax Code to keep making useful progress. Make it clear what must be true for the Goal to be complete and how that result will be verified. For example: “Upgrade the payment module to the new SDK, keep checkout and refund flows working, and make all related integration tests pass.” Upgrading the SDK is the outcome, preserving the business flows is a constraint, and passing integration tests is the acceptance evidence. Constraints describe what must remain true after the main outcome is achieved, such as keeping correctness tests green or preserving public API behavior. Working boundaries define which files, tools, and data MiniMax Code may use or modify. After each attempt, use the latest evidence to choose the most promising next action and record the result. Stop substantive work and report the blocker when required data is missing, validation tools cannot run, additional permission is needed, or no reasonable path remains within the agreed boundaries. You can use this structure: ```text theme={null} Achieve [final outcome] and verify it with [specific tests, reports, or artifacts]. Preserve [conditions that must not regress] throughout the work. Only use or modify [allowed files, tools, and data]. After each attempt, record [the change, result, and next experiment]. If [blocking condition] occurs, stop trying and report the approaches already attempted, available evidence, the cause of the blocker, and the input required to continue. ``` If you are unsure how to write one, describe the task in natural language and ask MiniMax Code to draft a Goal. Before using the draft, confirm that it defines the completion criteria, validation method, constraints, working boundaries, and blocking conditions. The user should still make the final decision about what counts as complete. ## When should I avoid Goal? * **The destination is vague or cannot be verified:** Requests such as “optimize this,” “refactor this code,” or “make it better” do not provide reliable completion criteria. First narrow the request to an outcome that can be evaluated with tests, metrics, artifacts, or evidence. * **The task should finish in one step:** A regular prompt is enough for a one-line change, simple explanation, short code review, or question that only needs one answer. * **Success depends mainly on subjective judgment:** Visual design, copy direction, and business tradeoffs are difficult to validate with tests alone. Keep human review at key stages. * **The work involves high-impact actions:** Production changes, deleting or overwriting data, paid operations, external publishing, and sending messages should retain explicit human confirmation. ## What should I keep in mind? **Watch usage:** Goal can run for multiple turns and may use substantially more resources than a one-time prompt. Set a time, attempt, or usage limit before starting. Pause or edit the Goal if the limit is reached, there has been no progress for two consecutive attempts, or the work is moving in the wrong direction. * **Verify completion with real evidence.** When MiniMax Code marks the Goal as complete, inspect the relevant test results, build output, benchmark, logs, or final artifacts. * **Define the allowed scope in advance.** Specify which files, tools, and environments may be used, as well as any directories, data, or existing behavior that must not be changed. * **Set an exit path for blockers and long-running work.** If permission is missing, an external service is unavailable, or repeated attempts keep reaching the same failure, pause the Goal and report the available evidence, the blocker, and what is needed to continue.