How to prompt Mistral Large

Prompt Mistral Large as a complete instruction: a short role, a concrete task, and a structure someone with no other context could follow. Mistral’s prompting guide starts there. A system message sets behavior for the conversation. A user message carries the specific request. If you cannot set a system message, put the standing instructions in the user message ahead of the query. Either split is allowed. The guide says to try both.

The same page asks for hierarchical sections, objective measures instead of words like “short” or “better,” and no contradictions once the system text gets long. It also says not to make the model count words or characters itself, and not to ask it to generate more text than the task needs. Formatting can be Markdown or XML-style tags. The point of the format is that sections stay separable.

A Mistral prompt that reads like a chat message (“could you maybe…”) is the opposite of that. State the deliverable, the limits, and the output shape in labeled blocks. Leave the pleasantries out.

The prompt structure

Role: Senior Python reviewer.

Task: Find the bugs in the function below and fix them.

Context:
Function parses ISO dates from a CSV export. Some rows have
timezone offsets, some don't.

Constraints:
- Return the corrected function plus a change list.
- Keep the function signature.
- Standard library only.

Output format:
Fenced Python code, then "Bug → Fix" bullets.

For a simple request, Role plus Task is enough. Add the other blocks when the work needs them.

Write system-style, not chat

Write the prompt as instructions the model receives, not as a message to a colleague. Leave out “I was wondering if you could perhaps…”, “please” and “let me know if you need anything else”. Those phrases soften the task, and Mistral answers soft requests with suggestions.

Strong verbs

“Implement”, “fix”, “write”, “summarise”. If you want a deliverable, ask for the deliverable, not a recommendation about it.

Constraints as dense bullets

Mistral handles compact lists well. Put every limit in the Constraints block, and only there. Repeating a limit in both Task and Constraints makes it more likely one copy gets dropped.

Phrase constraints positively where you can, and use placeholders such as [TBD] for missing facts instead of letting the model invent APIs, ticket IDs or audiences.

Name the output shape

Say exactly what comes back: an email with Subject and Body, markdown with H2 sections, or fenced code followed by change bullets. Put language and length in Constraints or Output format.

Keep the role to one line

“Senior reviewer” is enough. A paragraph of persona biography repeats the task and uses up the prompt’s focus.

Why Mistral prompts go wrong

• Long, rambling preambles.
• Soft verbs (“could you look at”).
• No output contract.
• Few-shot samples the model imitates instead of doing your task.
• XML tags it may echo back.
• Unrequested “think step by step” slogans on simple tasks.

When does a Mistral Large prompt fight itself?

Mistral’s own “what to avoid” list is more specific than “be clear.”

Blurry quantities. “Too long,” “a few,” “make it better,” and “interesting” are named as words to replace with an objective measure. “About 600 words” is still a measure. “Not too hypey” needs a concrete stand-in, such as “no hype adjectives,” or it stays a vibe.

Contradictions in a long system prompt. The guide’s example is two rules that both seem to apply to new data: update the old record, or create a new one. The fix they show is a decision list, not a second adjective. If your Constraints block says “cover every change” and “keep it to one paragraph,” say which one wins.

Asking the model to count. Mistral says not to make the model decide whether something is over a length limit by counting it. Pass the count in, or state the limit as an instruction without asking the model to measure its own output as a precondition.

Generating a whole artifact you will throw away. Models ingest tokens faster than they emit them. Asking for a full draft plus a second full draft “just in case” is the pattern their docs flag. Ask for the post, not the post and a spare post.

Keep the role to a line. Mistral’s own examples open with “You are a…, your task is to…”, then sections for the allowed values and the response format. A paragraph of persona biography repeats the task. Put every limit in Constraints once. Repeating it in Task and again in Output is how a long system prompt grows the contradictions the guide says to replace with a decision list. If a fact is missing, write a placeholder such as [launch date TBD] instead of a plausible invention the model will treat as given.

What does the same rough prompt look like for Mistral Large?

The input below is the shared draft. The labeled version only restates facts that draft already contains.

write a blog post announcing our windows app is moving from 1000 one-off credits to a flat 13.99 a month plan, about 600 words, its for people already using it, dont be hypey

Role: Write an announcement for people who already use the product.

Task: Write a blog post about the Windows app's pricing change.

Context:
- Old: 1,000 one-off credits.
- New: a flat 13.99 a month.
- Audience: people already using the app.

Constraints:
- About 600 words.
- No hype adjectives.
- Name both prices.

Output format:
Prose announcement. No alternate draft.