This guide explains how to write system prompts — the instructions that sit behind an AI assistant and shape how it behaves across a whole conversation or application. It covers what belongs in a system prompt, how to structure one so it actually gets followed, and how to test and refine it over time. It is written for anyone building with a language model, from a developer wiring an assistant into a product to a power user setting up a custom chatbot, and it assumes no prior prompt-engineering experience.
What a System Prompt Is For
Every conversation with a language model has two layers of instruction. The user prompt is what the person asks in the moment. The system prompt is the standing instruction that frames everything: who the assistant is, what it should do, what it should avoid, and how it should respond. Think of it as a job description plus a house style guide, given once, that applies to every request that follows.
A good system prompt answers four questions. First, role: what is the assistant, and what is it trying to accomplish? Second, audience: who is it talking to, and what do they already know? Third, boundaries: what must it never do, and what should it do when it cannot comply? Fourth, format: how should answers be structured, how long should they be, and what tone should they use? Leaving any of these vague forces the model to guess, and guesses vary from one conversation to the next. The goal is not to write a long prompt; it is to remove ambiguity about the things that matter most.
A common mistake is stuffing the system prompt with examples of every possible situation. Examples help, but a handful of representative ones beats a long catalogue. Another mistake is contradicting yourself — for example, telling the model to "always be concise" and then also asking for "thorough explanations with full detail." When instructions conflict, the model has to pick, and its pick may not be yours. Read your prompt back as if you were a new employee on their first day: if two instructions pull in opposite directions, rewrite one of them.
How to Structure and Test One
Structure helps the model follow instructions reliably. Start with the role and goal in one or two sentences. Follow with the rules that matter most, phrased as direct statements rather than wishes: "Cite sources for factual claims" works better than "It would be nice if you cited sources." Put hard constraints — safety rules, forbidden content, required formats — in their own short section so they stand out, and put output format last, since instructions near the end of a prompt tend to be followed closely for formatting.
Testing is where most system prompts actually get good. Write a small set of test questions that cover the hard cases: a request the assistant should refuse, a vague question it should clarify, a topic where it should admit uncertainty, and a formatting requirement it must honour. Run the same tests after every edit, because a change that fixes one case often breaks another. Keep the test set short enough that you will actually run it, and keep notes on what each version changed. Prompt engineering is iterative by nature; the first draft is rarely the one you ship.
One more habit pays off: separate stable instructions from per-conversation context. The system prompt should hold what is true for every conversation — role, rules, style. Details that change per user or per task belong in the user message or in retrieved context, not baked into the system prompt. This keeps the prompt shorter, easier to maintain, and less likely to go stale.
Why it matters
System prompts matter because they are the cheapest lever in an AI application. Changing a model is expensive; retraining one is more expensive still. Rewriting a few lines of system prompt costs nothing and can change behaviour more than either. Teams that treat the system prompt as a real, versioned piece of product — reviewed, tested, and updated deliberately — get noticeably more consistent assistants than teams that treat it as an afterthought.
The practical payoff is reliability. An assistant with a clear, tested system prompt behaves the same way on Monday as on Friday, refuses gracefully instead of improvising, and formats its answers so users can actually use them. As AI assistants move from novelties into tools people depend on, that consistency is what turns a clever demo into something trustworthy. Writing the prompt well is not a trick for squeezing better answers out of a model; it is the ordinary engineering work of defining what a product should do.
A VCTRIA evergreen guide.
