This is the most complete source in this batch and the one best suited for direct conversion into M3 usage guidelines. The official documentation covers general prompting, output formats, long context, tool use, reasoning depth, long-running agent tasks, and prompt evaluation and iteration.
The task, constraints, priorities, and desired output must be explicit. The official golden rule is: show the prompt to a colleague who knows nothing about the context; if they would be confused, the model will be too.
Explain the reasons behind constraints so the model can make tradeoffs among format, safety, accessibility, and workflow.
Use 3–5 relevant, differentiated, concrete examples for difficult classification, extraction, and boundary-setting tasks.
For repeated tasks, use a template with named variables so you can compare versions, locate regressions, and keep behavior stable.
Separate content with short labels such as Task, Context, Source, Constraints, and Output format; avoid deep nesting.
In long contexts, put the task after the source; number the sources, add dates, and mark clear boundaries; define priorities when sources conflict.
Tool prompts should clearly state the tool's purpose, when to use it, when not to use it, its parameters, return structure, and failure behavior.
Define explicit stopping rules: stop retrying after a tool fails twice and explain the blocker; do not call tools just to “look busy.”
Require deep reasoning for complex planning, debugging, and tradeoffs; for extraction, rewriting, and formatting, ask for direct output rather than requiring deep thinking every time.
Allow the model to refuse and cite its basis, reducing hallucinations about versions, prices, policies, and API behavior.
Keep only a small number of active goals in long tasks, with the plan, status, and open questions in visible context; split work across windows when necessary.
Prepare 10–30 representative test cases for important prompts, compare candidate versions, record regressions, and maintain a change log.
Task: [specific task to complete]
Context: [project background, tech stack, and why this approach is used]
Source: [files, logs, requirements, or API documentation]
Constraints:
- [required boundaries]
- [when to use tools and when not to]
- [how to handle failures]
Process:
1. First inspect the existing project and tests.
2. State a plan before implementing it.
3. Run relevant validation after each change.
Output format:
- Summary
- Changed files
- Tests and results
- Remaining risksPrompt patterns for using MiniMax Token Plan models effectively in coding, tool-use, agentic, and long-context workflows… This is a necessary excerpt; read the original source for full context.
This is a general official M-series document, not a single-task experiment focused only on M3. Official examples should serve as a skeleton, but they still need to be tested on your own project.
MiniMax M3