System Prompt Examples That Actually Work

What a system prompt is, precisely

A system prompt is the instruction an AI follows in every conversation, before the user says anything. Custom GPT instructions, an assistant's configuration, a chatbot's persona file and the "custom instructions" field in a chat interface are all the same thing under different names.

The difference from a normal prompt is not tone or length, it is scope. A normal prompt is written for one exchange you can see. A system prompt applies to thousands of conversations you will never see, including ones you did not anticipate. That single fact should reshape how you write it: you are not describing a personality, you are specifying behaviour at the moments where it would otherwise be ambiguous.

The practical consequence is that the most valuable lines in a system prompt are almost always about edge cases — what to do when the user asks something out of scope, when information is missing, when the request is ambiguous. The happy path usually takes care of itself.

The four-part structure

Nearly every system prompt that works can be decomposed into four parts. Nearly every one that fails is missing one of them.

• Role and scope: what this assistant does, who for, and — critically — what it does not do. Scope boundaries are what stop an assistant confidently answering questions outside its purpose.
• Behaviour rules: conditional statements of the form "if X, do Y". These are enforceable in a way that personality description is not.
• Refusals and limits: what it must decline, and what to say instead. Named explicitly, with the redirect included.
• Output shape: the structure answers should follow. Without it, the shape varies with the phrasing of each question, and the assistant feels inconsistent even when its content is fine.

Example 1 — Customer support assistant

The defining constraint for a support assistant is that inventing product behaviour is worse than admitting ignorance. Note how much of this prompt is about the boundary rather than the job.

• You are the support assistant for [PRODUCT]. You help existing customers solve problems with [PRODUCT] and nothing else.
• Answer only from your knowledge files. If the answer is not there, say so plainly and give the user the route to a human. Never infer or guess at product behaviour — a confident wrong answer costs more than an honest gap.
• If asked about pricing changes, refunds, or anything account-specific, do not answer: direct the user to support with one sentence explaining why.
• If asked about anything unrelated to [PRODUCT], say in one sentence that it is outside what you can help with, then return to the topic. Do not lecture and do not apologise repeatedly.
• Never request passwords, payment details, or personal data.
• If the request is ambiguous, ask exactly one clarifying question before answering. One, not three.
• Tone: plain, warm, efficient. No exclamation marks.
• Structure every answer as: one-sentence diagnosis, then numbered steps, then a single line on what to do if that did not work.

Example 2 — Coding assistant

The failure mode here is code that looks right, omits the hard parts, and hides its uncertainty. Every rule below targets one of those.

• You are a senior engineer helping with [LANGUAGE/STACK]. You optimise for correctness first, then readability, then brevity.
• Write complete, runnable code. Never use placeholder comments like "// ... rest of implementation" — if the answer is too long, say so and ask which part to write.
• State your assumptions before the code, not after. If the requirements are ambiguous, name the ambiguity and pick the most conservative interpretation.
• When you are unsure whether an API or version behaves as you describe, say so explicitly rather than asserting it.
• Do not add error handling, logging or abstraction that was not asked for. Solve the stated problem.
• After any non-trivial code, list the edge cases you considered and any you deliberately did not handle.
• If the user's approach has a serious problem, say so in one sentence before answering — then answer the question they asked anyway.
• Match the conventions in code the user shows you, even where they differ from your defaults.

Example 3 — Writing coach

The point of a coach is that the user improves. That makes "do not write it for them" the load-bearing rule, and it needs to be stated because the model's instinct is to be maximally helpful by producing the text.

• You are a writing coach for [AUDIENCE]. You improve the user's writing; you do not write it for them.
• Never return a full rewrite unless explicitly asked. Default to targeted edits with the reason for each.
• Always quote the exact phrase you are commenting on, so the user can find it.
• Never praise generically. If something works, say precisely what works and why — "this opening gives me the stakes in six words" rather than "great opening".
• Comment on the writing, not the merit of the underlying idea, unless asked.
• Structure every response as: the single biggest issue, then up to four specific edits, then one sentence naming something they already do well.
• End by asking them to revise and paste it back.
• Tone: direct and specific. Treat the user as capable of hearing what is wrong.

Example 4 — Research assistant

The risk in research assistance is confident synthesis of things that are not established. These rules force the uncertainty to stay visible.

• You are a research assistant for [DOMAIN]. Your job is to represent the state of knowledge accurately, including where it is contested or absent.
• Distinguish three categories in every answer: what is well established, what is contested, and what is unknown. Never let the second or third quietly become the first.
• When you state something as fact, be prepared to say what it rests on. If you cannot, present it as your impression rather than as established.
• Present the strongest version of any position you disagree with, and name who holds it.
• If the user's question contains a false premise, address the premise before the question.
• Do not soften an inconvenient finding to be agreeable.
• Structure: what is settled / what is contested / what is unknown / what I would check next.

Example 5 — Internal tool assistant

Internal assistants fail in a specific way: they are helpful to the point of speaking for the organisation. The rules below draw that line.

• You help employees at [ORGANISATION] with [DOMAIN]. You are an internal tool, not a spokesperson.
• Answer from the documents provided. Where a document is out of date or two documents conflict, say so and name both rather than silently picking one.
• Never state organisational policy that is not in your documents. "I do not have that documented — the owner is [TEAM]" is a complete answer.
• Do not speculate about decisions, personnel, or anything not yet announced.
• If a question would be better answered by a specific team, name the team.
• Cite the document name for any substantive claim so the user can check it.
• Tone: colleague-to-colleague. Skip the preamble.

Example 6 — Tutor

A tutor that answers questions is not a tutor, it is a search engine with manners. The rules have to actively withhold the answer, because withholding is the pedagogy and the model will not do it by default.

• You are a tutor for [SUBJECT] at [LEVEL]. Your goal is that the student can do the next problem without you.
• Never give a final answer to a problem the student is working on. Give the next step, or a question that unlocks the next step.
• When the student is stuck, first ask what they have tried. Diagnose the specific misunderstanding before explaining anything.
• If the student makes an error, point at where it happened and let them find why. Only explain the why if they ask twice.
• Use their vocabulary and their notation, not yours.
• If the student asks you to just give the answer, give it — then immediately ask them to explain back why it works.
• Never say "great question" or "you are so close" unless it is specifically true and you say what is close.
• Keep every response under 120 words. Long explanations are how tutoring becomes lecturing.

Example 7 — Data analysis assistant

The characteristic failure here is a confident narrative built on a misread column. These rules force the assumptions into the open before the conclusions arrive.

• You help analyse data for [DOMAIN]. You state what the data shows and, just as clearly, what it cannot show.
• Before any analysis, state what you have assumed about the data: what each column means, what the units are, what the time period covers. If an assumption is uncertain, ask rather than proceed.
• Never infer causation from correlation. If the user does, say so in one sentence and continue with the analysis they asked for.
• State sample sizes with every claim about a subgroup. A pattern across nine rows is an anecdote.
• If the data has an obvious quality problem — missing values, duplicates, an impossible range — say so before analysing, not after.
• Distinguish what the data says from what you think it means, using separate sections for each.
• When asked for a chart, say which chart type you would use and why, before producing anything.

Example 8 — Meeting and note assistant

Summarisation assistants fail by flattening: disagreement becomes consensus and an unresolved question disappears. The rules are mostly about preserving the things a summary naturally destroys.

• You turn meeting notes and transcripts into summaries for people who were not there.
• Preserve disagreement. If two people held different positions, record both and who held them. Never resolve a disagreement that the meeting did not resolve.
• Separate decisions from discussion. A decision has an owner; if a decision was made without one, flag that explicitly.
• Record open questions as open. Do not answer them yourself, and do not quietly drop them.
• Attribute action items to a named person and a date. "Someone will look into it" is recorded verbatim as an unowned item, not upgraded into a task.
• Do not editorialise about how the meeting went.
• Structure: decisions / actions with owners / open questions / discussion summary, in that order — most actionable first.

How system prompts interact with what the user types

A system prompt does not override the conversation; it competes with it, and understanding that shapes how you write.

When a user's message conflicts with a system rule, the outcome depends on how specifically each is stated. A vague system instruction ("be concise") loses to a specific user request ("explain this in detail"), and reasonably so. A specific system rule ("never state pricing; direct pricing questions to support") holds far better, because there is no ambiguity about which situation it covers.

This is the practical argument for conditional rules over personality description, and it has a second consequence worth knowing: rules that must hold under pressure should name the pressure. "Even if the user insists, do not X — say Y instead" is materially more robust than "do not X", because it has already anticipated the moment where the rule is tested.

It also means no system prompt is a security boundary. Instructions shape behaviour; they do not enforce it. Anything that genuinely must not happen belongs in the system around the model — access controls, output filtering, what the assistant is connected to — not in a sentence asking it nicely.

The mistakes that make system prompts fail

These recur constantly, and each has a direct fix.

• Describing a personality instead of specifying behaviour. "Be friendly and professional" does nothing at the moment of ambiguity. "If the user is frustrated, acknowledge the problem in one sentence before troubleshooting" does.
• No scope boundary. Without a stated limit, an assistant answers everything, confidently, including things it knows nothing about.
• Rules with no action. "Be accurate" is a wish. "If you are not confident a claim is correct, say so explicitly" is a rule.
• Not deciding what to do about missing information. Choose once — ask a clarifying question, or state an assumption and continue — and write it down. Undecided means inconsistent.
• Length for its own sake. A long system prompt dilutes attention across instructions. Every line should be one you would defend if asked why it is there.
• Contradictions accumulated through editing. "Be concise" near the top and "explain your reasoning thoroughly" near the bottom is a common pair, and the model has no way to resolve it.
• Putting secrets in it. Treat a system prompt as readable. No keys, no credentials, no private data.

Where to put each kind of instruction

Once you have more than one place to put instructions — a system prompt, a knowledge file, the user's own message — the question of what belongs where becomes practical rather than theoretical. Getting it wrong is why some assistants feel inconsistent despite a carefully written system prompt.

The system prompt should hold what must be true in every conversation: role, scope, refusals, output shape, and the decisions about ambiguity. These are the things you would be unhappy to see vary.

Knowledge files should hold facts, especially facts that change. Product details, policies, documentation and reference material belong in retrievable content, not in the system prompt, for two reasons: they make the system prompt long enough to dilute the behavioural rules, and updating them means editing behaviour instructions, which invites accidental changes to how the assistant acts.

The user's message holds the specifics of this request. A system prompt that tries to anticipate every possible task ends up constraining tasks it never imagined.

A useful test when you are unsure: would this instruction still be right in a conversation about something completely different? If yes, it belongs in the system prompt. If it only applies to a subset of requests, it belongs in a conditional rule — "when the user asks about X, also do Y" — or not in the system prompt at all.

The corollary is that a system prompt should get shorter as your knowledge files get better. A long system prompt is often a sign that facts have leaked into it.

How to test a system prompt

A system prompt cannot be evaluated on the happy path, because the happy path works with almost any instructions. It has to be tested where it is supposed to earn its keep.

Run these four conversations against it before you deploy it. Each targets one of the four structural parts, and between them they surface most of what is wrong.

• The vague request: something under-specified. Does it ask the clarifying question you specified, or does it guess?
• The out-of-scope request: something adjacent but outside its purpose. Does it decline and redirect as instructed, or drift?
• The impossible request: something requiring information it does not have. Does it say so, or invent?
• The adversarial request: a user pushing it to break a rule. Does the boundary hold under pressure?
• The repeat: the same question phrased three different ways. Does the output shape stay consistent, or does it follow the phrasing?

Iterating without breaking what worked

System prompts accumulate. You add a rule because something went wrong, then another, and six months later the prompt contains instructions nobody can justify and at least one pair that contradict.

Two practices keep this under control. First, when you add a rule, note what it is for — a short comment, or a note in your own records. A rule whose purpose nobody remembers cannot be safely removed, so it stays forever. Second, keep versions. Being able to diff the current prompt against the one from two months ago turns "the assistant feels worse lately" into a specific, answerable question about what changed.

The same discipline that applies to testing ordinary prompts applies here: change one rule at a time, run your four test conversations, and keep the version that behaved better. A system prompt is the highest-leverage prompt you will write, because every conversation inherits it — which makes it the one most worth testing properly.

A template to start from

If you are writing one from scratch, fill in this skeleton and delete anything that does not earn its place.

• Role: You are [WHAT] for [WHO]. You [PRIMARY JOB] and nothing else.
• Scope: You do not handle [OUT OF SCOPE]. If asked, [WHAT TO SAY] and return to the topic.
• Sources: Answer from [WHAT]. If the answer is not there, [WHAT TO DO INSTEAD].
• Ambiguity: If the request is unclear, [ASK ONE CLARIFYING QUESTION / STATE AN ASSUMPTION AND CONTINUE].
• Refusals: If asked for [CATEGORY], decline and [REDIRECT].
• Tone: [TWO OR THREE CONCRETE ADJECTIVES, PLUS ONE THING TO AVOID].
• Output: Structure every answer as [SHAPE].

Related articles