30 Best Mistral Prompts 2026: Copy-Paste Templates for Le Chat & Mistral Large

Read the document below and produce a structured summary in three 
languages: English, French, and [THIRD LANGUAGE].

Document:
[PASTE TEXT]

For each language version:
1. 5-bullet executive summary (under 100 words)
2. 3 key quotes preserved in their original language
3. One sentence flagging anything that doesn't translate cleanly 
   (idiom, regulatory term, cultural reference)

Match register to the source. If the original is formal business 
French, don't render the English in casual tone. Localize the 
examples to each market where the meaning would otherwise be lost.

I'm publishing the following marketing copy in [SOURCE LANGUAGE]. 
Check it for [TARGET MARKET — e.g., France, Quebec, Germany, Mexico, 
Spain] suitability.

Copy:
[PASTE]

Review:
1. Cultural references that won't land or could offend
2. Idioms that translate awkwardly
3. Formality level — is it too informal/formal for this market?
4. Specific words or claims that have legal/regulatory implications 
   in this market
5. Brand tone — does this match how brands actually communicate in 
   this market in 2026?
6. Three rewrites of the headline that would work better locally

Be direct. If the copy reads like it was written by someone who's 
never lived in [MARKET], say so.

Rewrite the message below in [LANGUAGE] at three register levels:

1. Formal/business (the version you'd send to a director you've 
   never met)
2. Standard professional (the version you'd send to a peer at 
   another company)
3. Casual professional (the version you'd send to a colleague 
   you work with daily)

Original message:
[PASTE]

For each version, show:
- The rewritten message
- 3 specific word/phrase choices that signal the register
- One mistake non-native speakers commonly make at this register

Languages I'll likely use this for: French, German, Spanish, Italian. 
Match the conventions of native business communication in that country, 
not a generic "polite" register.

Draft a customer support reply in [CUSTOMER'S LANGUAGE].

Customer message:
[PASTE — keep original language]

Context:
- Product: [DESCRIPTION]
- Issue category: [BUG / BILLING / FEATURE REQUEST / COMPLAINT]
- What I can offer: [REFUND / FIX TIMELINE / WORKAROUND / ESCALATION]
- Customer's apparent emotional state: [FRUSTRATED / CONFUSED / ANGRY / NEUTRAL]

Reply requirements:
- Match the customer's language exactly (including regional variant — 
  European Spanish vs Latin American Spanish matters)
- Acknowledge the specific issue, don't generalize
- Use natural support language for that market — not a translation 
  of American customer service speak
- One concrete next step
- Brief, warm, professional

Then provide an English summary for my records.

Write the following compliance text in English, French, German, and 
Spanish, suitable for publication on an EU-facing website.

Compliance text needed: [e.g., privacy policy summary, cookie banner 
text, terms update notice, GDPR data request response template]

Context:
- Company: [NAME, TYPE OF BUSINESS]
- Jurisdiction: [WHICH EU MEMBER STATES MATTER]
- Specific regulations referenced: [GDPR, DSA, AI Act, etc.]
- Required reading level: [PLAIN LANGUAGE / LEGAL / TECHNICAL]

For each language:
- The compliance text itself
- 3 terms-of-art that needed careful translation (with reasoning)
- One sentence flagging if local law differs from the harmonized 
  EU baseline for that jurisdiction

I am not a lawyer and you are not my lawyer. Flag anything I should 
have a local lawyer review.

Review this code as a senior engineer would in a pull request.

Language: [LANGUAGE]
Framework: [IF APPLICABLE]
What this code does: [BRIEF DESCRIPTION]
What I want feedback on specifically: [PERFORMANCE / READABILITY / 
SECURITY / IDIOMATIC STYLE / ALL OF THE ABOVE]

Code:
[PASTE]

Provide:
1. Bugs or correctness issues (with line references)
2. Security concerns (with severity)
3. Performance issues (with estimated impact)
4. Idiomatic improvements (where it's not wrong, just not how a 
   senior dev would write it)
5. Test coverage gaps — what cases isn't this handling?
6. One question I should ask the author before approving

Rank findings by severity. Don't pad the review with nitpicks.

Convert this code from [SOURCE LANGUAGE] to [TARGET LANGUAGE].

Source:
[PASTE CODE]

Requirements:
- Idiomatic [TARGET LANGUAGE] — don't translate syntax word-for-word
- Use [TARGET LANGUAGE] standard library equivalents where possible
- Preserve error handling, adapt to target conventions
- Flag any feature with no direct equivalent and explain your workaround
- Match the source's behavior exactly for the common path; note 
  any edge case where behavior diverges
- Output: just the converted code first, then a short "Notes" 
  section below

Bonus: tell me whether this code is worth porting at all, or 
whether [TARGET LANGUAGE] has a built-in/library that solves the 
same problem better.

Generate a test suite for this code.

Language: [LANGUAGE]
Testing framework: [PYTEST / JEST / JUNIT / etc.]
Code under test:
[PASTE]

Generate:
1. Happy-path tests (the common usage)
2. Edge cases (empty input, null/undefined, boundary values, max size)
3. Error cases (invalid input, network failure, permission denial)
4. Regression tests for any subtle behavior you spot in the code

For each test:
- Descriptive name (no "test_function_1" garbage)
- Setup / action / assertion structure
- A one-line comment if the test exists to prevent a specific 
  category of bug

Don't generate 80 useless tests. Generate 15-25 tests that actually 
catch bugs.

This code is slower than I need. Help me optimize it.

Code:
[PASTE]

Context:
- Language: [LANGUAGE]
- Current performance: [TIME / THROUGHPUT]
- Target: [WHAT "FAST ENOUGH" LOOKS LIKE]
- Dataset size: [ROWS / OBJECTS / MB]
- Constraints: [WHAT I CAN'T CHANGE — language, framework, schema]

Walk me through:
1. Where is time actually being spent? (algorithmic complexity, 
   I/O, allocation, lock contention, etc.)
2. The single highest-impact change
3. The optimized code for that change
4. Estimated improvement (order of magnitude is fine)
5. Two secondary optimizations ranked by effort:impact
6. One thing I should profile to confirm the bottleneck before 
   applying any of this

Don't propose micro-optimizations if there's an algorithmic problem.

Write a SQL query for [DATABASE — Postgres, MySQL, SQLite, 
BigQuery, Snowflake, etc.].

Schema:
[PASTE RELEVANT TABLES AND COLUMNS, OR DESCRIBE]

I need to answer this question:
[NATURAL LANGUAGE QUESTION]

Requirements:
- Correct, executable SQL for the specified database dialect
- Use CTEs over nested subqueries where it improves readability
- Include indexes I should have for this query to perform well
- Show the query plan would look (in plain English) for a table 
  with ~[ROW COUNT] rows
- If the question is ambiguous, list your assumptions and ask 
  before producing a single complex query that solves the wrong problem

Output:
1. Clarifying questions (if any)
2. The query
3. Expected behavior in plain English
4. Index recommendations

Refactor this code without changing its behavior.

Code:
[PASTE]

Goals (rank order):
1. [READABILITY / TESTABILITY / SEPARATION OF CONCERNS / REMOVE DUPLICATION]
2. [SECONDARY GOAL]
3. [TERTIARY GOAL]

Constraints:
- Same public API (function signatures, return types, side effects)
- Same observable behavior for all inputs
- [LANGUAGE]-idiomatic
- If you split into multiple functions/classes, justify each split

Output:
1. Refactored code
2. A one-paragraph "what I changed and why"
3. Anything I should manually test to confirm equivalence
4. Anything I noticed during refactor that's a latent bug 
   (don't fix it — just flag it)

Rewrite the marketing copy below to be GDPR-compliant and read 
naturally to EU consumers.

Original copy (US-style):
[PASTE]

Target market: [SPECIFIC EU COUNTRIES]
Product: [WHAT IT IS]
Data we actually collect: [LIST]

Audit:
1. Claims that imply data collection beyond what's necessary 
   (data minimization principle)
2. Consent language that's vague or pre-checked
3. "Free" framing where there's a data trade
4. Personalization claims that need a legal basis
5. Phrases that read as "American marketing" to a European reader

Then rewrite:
- Compliance-aware (without sounding like a legal document)
- Natural in [PRIMARY EU TARGET LANGUAGE]
- Honest about the data exchange

I'd rather have boring honest copy that converts than aggressive 
copy that triggers a regulator complaint.

Write a business email in French to [RECIPIENT — describe role and 
seniority].

Goal: [WHAT I WANT FROM THIS EMAIL]
Context: [PRIOR RELATIONSHIP, IF ANY]
Tone: [FORMAL / WARM-PROFESSIONAL / DIRECT]
Length: [SHORT / MEDIUM]
Deadline or response expected by: [IF APPLICABLE]

Requirements:
- Use the correct opening based on relationship and seniority 
  ("Madame," "Cher Monsieur," "Bonjour [Prénom]" — pick correctly)
- Match French business email conventions, not a translation of 
  American directness
- Closing formula that fits the relationship
- If the request is delicate, signal it the way a French speaker would

Output:
1. The French email
2. An English back-translation (literal, not polished — so I can 
   verify nuance)
3. Three phrases to remember for future emails like this

Summarize the following document in German for a [AUDIENCE — 
compliance officer, board member, employee, general public].

Document:
[PASTE OR DESCRIBE]

Requirements:
- Plain German, not legal jargon (unless audience is legal)
- Match Germanic business writing conventions — direct, structured, 
  no marketing language
- Lead with the key takeaway (the "Bottom Line Up Front" pattern 
  works in German too)
- 3-5 bullets max for the body
- One sentence on what action is required, and from whom

If the document references EU regulation, use the German names 
(DSGVO not GDPR, KI-Verordnung not AI Act).

Brief me on [EU REGULATION — e.g., AI Act, DSA, DMA, NIS2, CSRD] 
as it applies to [MY BUSINESS DESCRIPTION].

Cover:
1. What the regulation actually requires (plain language)
2. Whether my business is in scope, and on what basis
3. The specific obligations I'd carry (if in scope)
4. Compliance deadlines and current enforcement status
5. The penalty range for non-compliance
6. The 3 most common compliance mistakes companies in my space are making
7. The cheapest meaningful step I could take this quarter

I am not a lawyer and you are not my lawyer. Cite which Article 
or section each obligation comes from so I can verify with counsel.

If the regulation has been amended or there's active EU guidance 
that changes interpretation, flag it.

I'm evaluating where to host [SERVICE/DATA]. Help me think through 
the data residency tradeoffs.

What we process:
- Data types: [PII, financial, health, IP, etc.]
- User regions: [WHERE OUR USERS ARE]
- Volumes: [APPROXIMATE]

Candidate regions:
- [REGION 1 — e.g., EU (Frankfurt)]
- [REGION 2 — e.g., US (Virginia)]
- [REGION 3]

For each region:
1. Regulatory regime that applies
2. Cross-border transfer implications (do I need SCCs, adequacy 
   decision, supplementary measures?)
3. Government access risk profile
4. Latency to my main user base
5. Cost trend in 2026
6. Operational complexity (do I need region-specific infrastructure?)

Recommend a primary region and any required secondary region. 
Flag anything where I should engage a privacy lawyer before deciding.

Summarize the document below. It's roughly [LENGTH] and Mistral 
should handle the full context.

Document:
[PASTE — up to ~100K tokens]

Produce:
1. One-sentence executive summary (the headline if this were a 
   news brief)
2. 5-bullet "if you only read this" summary
3. Section-by-section summary (200-300 words total, proportional 
   to section importance, not section length)
4. 5 direct quotes worth preserving verbatim
5. 3 questions the document raises but doesn't answer
6. One thing the document subtly assumes but doesn't argue for

Don't pad. If a section is one paragraph and doesn't matter, say so 
and skip it.

Compare what these sources say about [TOPIC].

Sources:
1. [PASTE OR DESCRIBE — Source A]
2. [PASTE OR DESCRIBE — Source B]
3. [PASTE OR DESCRIBE — Source C]
   [Add more as needed]

For each major claim about [TOPIC]:
- Which sources support it and how strongly
- Which sources contradict it
- Which sources are silent (and is that significant?)

Then:
1. Points of consensus across all sources
2. Live disagreements (and what evidence would resolve each)
3. Where one source is more credible on this specific point and why
4. What's missing from all of them
5. Synthesis: what's the most defensible position given these sources?

Don't false-balance. If 3 sources agree and 1 disagrees and the 
disagreeing source is weaker, say so.

Turn the following raw sources into a briefing for [AUDIENCE — 
executive, technical team, client, regulator].

Sources:
[PASTE — research papers, articles, transcripts, internal memos, etc.]

Briefing structure:
1. TL;DR (2-3 sentences)
2. Key findings (5 bullets, each with the source citation)
3. What's settled and what's contested
4. Risks/uncertainties the audience needs to know
5. Recommended next steps (3 max)
6. Appendix: which questions remain open and what sources would 
   resolve them

Tone: [MATCH AUDIENCE — board-level / technical / regulatory]
Length: [TARGET]

Cite specific sources for every non-obvious claim. If something is 
your synthesis rather than a source claim, label it clearly.

I have [N] research papers to read on [TOPIC]. Help me triage them.

Papers (titles and abstracts):
[PASTE TITLES + ABSTRACTS]

For each paper:
1. One-sentence summary of what it actually claims
2. Strength of the methodology (based on the abstract — flag if I 
   need the full paper to assess)
3. Relevance to my specific question: [QUESTION]
4. Read priority: must-read / skim / skip
5. If "skip" — what would change that recommendation

Then:
- The 3 papers I should read in full this week
- The 2 papers worth a 5-minute skim
- The papers I can safely ignore for my question

If multiple papers cover the same ground, tell me which one supersedes 
the others.

You have access to this document. Answer questions about it with 
direct citations.

Document:
[PASTE]

For each of my questions:
1. Direct answer (or "the document doesn't address this")
2. The specific passage(s) that support the answer (quote the 
   passage and indicate its location)
3. Your confidence level (high / medium / low) and why
4. Any related question the document raises that I haven't asked

My questions:
- [QUESTION 1]
- [QUESTION 2]
- [QUESTION 3]

Rule: don't infer beyond what the document says. If the document is 
silent, say so. I'd rather get five "not addressed" answers than one 
hallucination.

Extract structured data from the text below and return valid JSON 
matching this schema.

Schema:
[PASTE JSON SCHEMA or DESCRIBE FIELDS]

Source text:
[PASTE]

Rules:
- Output valid JSON only, no commentary, no markdown fences
- Use null for genuinely missing fields, not empty strings
- Use ISO 8601 for dates (YYYY-MM-DD)
- Preserve original casing for proper nouns
- If the text is ambiguous on a field, choose the most defensible 
  interpretation and add a "_notes" field at the root explaining 
  ambiguities

If the text doesn't contain enough information to populate the 
required fields, return:
{"error": "<which fields are missing and why>"}

Extract all tables from the document below as structured data.

Document:
[PASTE]

For each table:
1. Table title or caption (or "Untitled #N" if none)
2. Column headers (exactly as in the source)
3. Rows as arrays of values
4. Footnotes or units (separately, not jammed into cells)
5. Output as JSON: { "tables": [ { "title": ..., "columns": [...], 
   "rows": [[...]], "notes": "..." } ] }

Rules:
- Preserve numeric values exactly (don't round, don't reformat)
- Empty cells: null, not ""
- Merged cells: repeat the merged value across the spanned positions
- If a table is poorly structured in the source, normalize it and 
  add a "_normalization_notes" field explaining what you changed

Generate a form schema for [USE CASE — e.g., customer onboarding, 
expense submission, research intake].

Required fields:
- [FIELD 1, with type and constraints]
- [FIELD 2]
- [FIELD 3]
[add more]

Output JSON in this shape:
{
  "form_name": "...",
  "fields": [
    {
      "id": "...",
      "label": "...",
      "type": "...",
      "required": true|false,
      "validation": { ... },
      "help_text": "...",
      "conditional_logic": { ... }  // if applicable
    }
  ],
  "submit_action": "..."
}

Rules:
- Types: text, email, number, date, select, multiselect, textarea, 
  file, checkbox
- Realistic validation (regex for emails, min/max for numbers, etc.)
- Help text only where a user might be confused
- Conditional logic: show field B only if field A == X
- Field order optimized for completion rate (easy fields first)

Convert these raw meeting notes into structured JSON.

Raw notes:
[PASTE TRANSCRIPT OR NOTES]

Output:
{
  "meeting": {
    "title": "...",
    "date": "YYYY-MM-DD",
    "attendees": ["..."],
    "duration_minutes": ...
  },
  "decisions": [
    { "decision": "...", "owner": "...", "rationale": "..." }
  ],
  "action_items": [
    { "task": "...", "owner": "...", "due_date": "YYYY-MM-DD", 
      "blockers": "..." }
  ],
  "open_questions": [
    { "question": "...", "raised_by": "...", "needs": "..." }
  ],
  "discussion_highlights": [
    { "topic": "...", "summary": "..." }
  ]
}

Rules:
- Only fields with evidence in the source
- Don't invent attendees or owners — use "Unassigned" or null
- Action items: if a date wasn't stated, leave null, don't guess
- Decisions are different from discussion — flag accordingly

I'm getting inconsistent responses from [API/SOURCE]. Normalize 
them into a consistent schema.

Sample inputs (variations):
[PASTE 3-5 EXAMPLES SHOWING THE VARIATION]

Target schema:
[PASTE OR DESCRIBE]

Output:
1. The transformation logic in pseudocode (so I can implement it)
2. The normalized JSON for each of the sample inputs
3. Edge cases your transformation handles
4. Edge cases it does NOT handle (where the input would need to be 
   rejected upstream)
5. Validation rules I should add before the transformation runs

Write [CONTENT TYPE — landing page, ad, email, social post] in a 
brand voice that fits [SPECIFIC EUROPEAN MARKET].

Brand context:
- Product: [WHAT IT IS]
- Position: [PREMIUM / VALUE / CHALLENGER]
- Audience: [WHO BUYS IT]
- Market: [FRANCE / GERMANY / NORDICS / SPAIN / ITALY / NETHERLANDS]

Tone requirements:
- Match how brands in this market actually communicate, not how 
  Americans imagine European brands communicate
- Avoid hyperbole that reads as American to European ears 
  ("revolutionary," "world-class," "best-in-class")
- Use the credibility signals this market responds to (heritage, 
  craftsmanship, design rigor, scientific backing — pick what fits)
- Right level of formality for the channel and market

Output:
1. Primary copy in [TARGET LANGUAGE]
2. English back-translation
3. 3 alternate headlines
4. One observation about how this differs from how the same product 
   would be marketed in the US

This concept needs to land in [MARKET]. Localize it — don't just 
translate it.

Concept (in source language):
[PASTE]

Target market: [COUNTRY/REGION]

Walk through:
1. What in this concept won't survive the move (humor, references, 
   metaphors, examples)
2. What needs to be replaced (with specific local equivalents)
3. What stays as-is
4. The localized version, in [TARGET LANGUAGE]
5. Three credibility moves you added that fit this market

Then: write one paragraph in English explaining the localization 
choices to a stakeholder who only speaks English. They'll want to 
know why you didn't just translate.

Generate taglines for [PRODUCT/CAMPAIGN] across [N] European markets.

Product: [DESCRIPTION]
Core promise: [WHAT IT DELIVERS]
Brand personality: [3-5 ADJECTIVES]
Markets: [LIST WITH PRIMARY LANGUAGE]

For each market, produce:
1. Three tagline options in the market's primary language
2. The one you'd actually pick, with reasoning
3. The cultural/linguistic reason it works in this market specifically
4. What to test against it (the runner-up option that might win)

Rules:
- Taglines: under 7 words ideally, 10 max
- Don't recycle the same tagline across markets with a translation — 
  each market gets a tagline written for it
- Avoid puns that only work in English
- Flag any tagline that has a competitor using similar language

Write a product launch announcement that we'll publish simultaneously 
in [LIST OF MARKETS/LANGUAGES].

Product: [WHAT WE'RE LAUNCHING]
Launch date: [DATE]
Key differentiator: [WHY IT MATTERS]
Press angle: [WHAT MAKES THIS NEWSWORTHY]

For each language version:
1. Headline (newsworthy, not promotional)
2. Subheadline
3. Opening paragraph (the 5W lead)
4. Body (200-300 words)
5. One quote from leadership, written in that language's natural 
   business communication style
6. Boilerplate "about the company" paragraph

Cross-version requirement:
- Same core facts, dates, and product details across all versions
- Tone and emphasis adjusted to market norms
- Quotes attributed to the same person but written natively per 
  language (not translated)

Flag any market where this announcement might land differently 
(regulatory sensitivity, competitive context, market timing).