System Prompt Examples You Can Copy for Coding and Support

A system prompt is the standing instruction you give a model before any user message arrives. It sets the role, the rules, the output format and the limits, so every reply in the conversation starts from the same ground. Good ones are short, specific and written as positive instructions.

Below are three templates you can paste in today (coding, support, writing), a short section on agents, and the structure behind them. The structure advice comes from Anthropic's prompting docs for Claude. The idea carries over to ChatGPT and Gemini, but test it on your own model.

What a system prompt is for#

Think of it as a job description, not a chat message. The user prompt says what to do right now. The system prompt says who the assistant is, what it can touch, how it should answer, and what to do when it isn't sure.

It's the right place for things that stay true across the whole conversation:

• The role and audience ("you help support agents at [PRODUCT]").
• The output format (plain text, JSON, a fixed template).
• Tone and length.
• Default behavior with tools: act, or ask first.
• Where to get facts, and what to say when they're missing.

It's the wrong place for one-off requests, or for facts that change per request. Put those in the user turn, or in a tagged block you fill in at runtime.

Most providers expose it as a separate field. Gemini, for example, takes a system_instruction parameter. Here's the smallest working call from Google's docs:

from google import genai

client = genai.Client()

interaction = client.interactions.create(
    model="gemini-3.8-flash",
    system_instruction="You are a cat. Your name is Neko.",
    input="Hello there"
)

print(interaction.output_text)

Swap the string for a real prompt and the rest stays the same. Check your own provider's docs for the equivalent field name.

How to write a system prompt#

A few habits cover most of the quality gap. All of them are in the Claude prompt engineering reference.

Wrap each kind of content in its own tag. XML tags like <instructions>, <context> and <input> help the model separate instructions from data. Use consistent, descriptive names, and nest tags when the content has a natural hierarchy.

Say what to do, not what to avoid. The docs contrast "Do not use markdown in your response" with "Your response should be composed of smoothly flowing prose paragraphs." The second version gives the model a target instead of a prohibition.

Match the prompt's style to the output you want. If your prompt is full of markdown, expect markdown back. Remove it from the prompt if you want less of it in the output.

Put long documents at the top. For inputs of 20k+ tokens, place the long material above your query, instructions and examples. Wrap multiple documents in <document> tags with <document_content> and <source> subtags.

Use normal language. Newer Claude models respond strongly to the system prompt. The docs say that where you might have written "CRITICAL: You MUST use this tool when...", plain "Use this tool when..." works better, because shouted rules can now overtrigger.

Here's a small script that assembles a prompt from named parts, so each section lands in its own tag. Edit the parts and rerun it.

parts = {
    'role': 'You are a code review assistant for a Python team.',
    'rules': 'Review only the diff you are given. Point to the line. Suggest a fix.',
    'format': 'Reply with a short list of findings, most serious first.',
}

prompt = '\n\n'.join(f'<{name}>\n{text}\n</{name}>' for name, text in parts.items())
print(prompt)
print()
print(len(prompt.split()), 'words')

I'd keep a prompt in a file under version control and build it like this, so edits show up in diffs.

System prompt example for a coding assistant#

The main decision for a coding assistant is whether it edits code or only talks about it. The Claude docs note that "Can you suggest some changes to improve this function?" gets suggestions, while "Change this function to improve its performance." gets edits. If you want edits by default, say so in the system prompt.

<role>
You are a coding assistant for a [LANGUAGE] project called [PROJECT].
</role>

<default_to_action>
By default, implement changes rather than only suggesting them. If the user's
intent is unclear, infer the most useful likely action and proceed, using tools
to discover any missing details instead of guessing.
</default_to_action>

<code_style>
Follow the conventions already present in the file you are editing.
Keep changes small and focused on the request.
</code_style>

<response_format>
After a change, give a short summary: what changed, in which files, and
anything the user should check.
</response_format>

Why it's worded this way. The default_to_action block is adapted from Anthropic's sample for proactive action. The summary line matters because, per the same docs, recent Claude models may skip verbal summaries after tool calls unless you ask. Everything else is a plain positive instruction.

If you want the opposite (research and advice first, edits only on request), the docs offer a do_not_act_before_instructions block: don't change files unless clearly instructed, and when intent is ambiguous, default to information and recommendations.

System prompt example for customer support#

Support prompts fail when the model invents policy. The fix is to hand it the policy, tell it where to look, and say what to do when the answer isn't there.

<role>
You are a support assistant for [PRODUCT]. You talk to customers in [LANGUAGE].
</role>

<policy>
[PASTE REFUND, SHIPPING AND ACCOUNT POLICY TEXT HERE]
</policy>

<instructions>
Answer using only the text in <policy>. If the policy does not cover the
question, say you are not sure and offer to pass the case to [HUMAN TEAM].
Keep answers under [N] sentences. Write in plain sentences, in a friendly,
direct tone.
</instructions>

Why it's worded this way. The policy sits in its own tag so the model can tell reference material from instructions. "Say you are not sure and hand off" gives it an exit, which does more than a bare "never guess". The tone line says what to write (plain sentences) rather than listing banned styles. Replace the bracketed length and handoff target with real values before shipping, or the model will see the brackets literally.

Support bots usually run for many turns, so the system prompt has to hold up. Test it with messages that try to pull the bot off topic, and re-read the prompt whenever the policy changes.

System prompt example for a writing assistant#

Writing assistants mostly need a voice and a format. Formatting is where the docs have the most to say: describe the output you want in positive terms.

<role>
You are an editor for [PUBLICATION], writing for [AUDIENCE].
</role>

<voice>
Write in clear, flowing prose using complete paragraphs. Use headings only for
long pieces. Keep sentences varied in length. Prefer concrete examples to
abstract claims.
</voice>

<task_handling>
When the user pastes a draft, return an improved version first, then a short
note on what you changed and why. When the user asks a question about writing,
answer it directly.
</task_handling>

Why it's worded this way. The voice block borrows from the docs' advice to ask for "smoothly flowing prose paragraphs" instead of saying "no markdown". Because the prompt itself has little markdown, the model has less reason to produce it. The task block covers the two cases you'll see most, so the model doesn't have to guess.

The docs also give a longer block for suppressing excess markdown, which is useful if your output keeps filling up with bullets. One caution from the same page: Claude Fable 5.1 already formats less than earlier models, so on that model a heavy anti-markdown block can remove structure the content needs.

Agent system prompt examples#

Agents add tools, and tool behavior is where system prompts earn their keep. Two blocks from the Claude docs are worth copying.

For parallel work, the docs suggest telling the model to make independent tool calls in parallel and sequential calls when one depends on another:

<use_parallel_tool_calls>
If you intend to call multiple tools and there are no dependencies between the
tool calls, make all of the independent tool calls in parallel. If some tool
calls depend on previous calls to inform dependent values like the parameters,
do NOT call these tools in parallel and instead call them sequentially. Never
use placeholders or guess missing parameters in tool calls.
</use_parallel_tool_calls>

For reflection after tool results, the docs give this sample:

After receiving tool results, carefully reflect on their quality and determine
optimal next steps before proceeding. Use your thinking to plan and iterate
based on this new information, and then take the best next action.

If the model seems to think more than you'd like, which the docs say can happen with large or complex system prompts, add a line telling it that thinking adds latency and should be used only when it will meaningfully improve answer quality, and to respond directly when in doubt. Thinking behavior and effort settings differ by model, so read the page for the one you run.

Common mistakes with system prompts#

Shouting. Capital letters and "MUST" and "NEVER" were a workaround for models that ignored instructions. On newer, more responsive models they can cause overtriggering. Write it the way you'd brief a colleague.

Only saying what not to do. A list of prohibitions leaves the model guessing what you do want. Rewrite each one as the behavior you're after.

Mixing data and instructions. Pasting a policy, a document and rules into one block makes them blur together. Tag them separately.

Leaving placeholders in. A stray [PRODUCT] goes straight to the model. The script below flags shouting, negative phrasing and unfilled placeholders in a draft prompt. It's a crude check, but it catches the obvious cases.

import re

prompt = '''You are a support assistant for [PRODUCT].
CRITICAL: You MUST NEVER guess. Do not use markdown.
Answer in plain sentences. Use the refund policy in <policy> when it applies.'''

checks = {
    'shouting': r'\b(?:CRITICAL|MUST|NEVER|ALWAYS)\b',
    'negative rule': r'\b[Dd]o not\b|\b[Dd]on.t\b|\bNEVER\b',
    'unfilled placeholder': r'\[[A-Z_ ]+\]',
}

for name, pattern in checks.items():
    hits = re.findall(pattern, prompt)
    print(f'{name}: {len(hits)} -> {sorted(set(hits))}')

Never testing it. A prompt that reads well can still behave badly. Run a fixed set of sample conversations after every edit, including the awkward ones, and compare outputs.

Copying someone else's giant prompt. Public collections on GitHub and Reddit are good for ideas, but a long prompt written for another product carries rules you don't need. I'd start small and add a line only when you've seen a specific failure.

System prompt quick reference#

Before you ship:

• Is the role stated in one or two sentences?
• Is each kind of content in its own tag?
• Are rules phrased as what to do?
• Is there no shouting or leftover [PLACEHOLDER]?
• Does the prompt say what happens when the answer is unknown?
• Have you run it against a fixed set of test conversations?
• Have you checked your model's own prompting page for quirks? Anthropic publishes one per Claude model, and Google's system instructions docs cover Gemini.

Quick answers