Gemini System Prompt: Set Instructions and Test Behavior
System instructions in Gemini let you set standing rules that apply to every message in a session. Here is how they work, what to put in them, and how to test them.
Updated 6 min read
A system prompt in Gemini — called system instructions in Google's documentation — is a set of standing rules you write once that the model reads before every user message. Instead of repeating "reply in formal English" or "focus only on legal questions" in every prompt, you write it once as a system instruction and it shapes every response in that session.
System instructions are available in the Gemini API and in Gem configurations. The two places work similarly but serve different purposes. When you need to keep your reviewed instructions and the test results that confirmed they work, a tool like fenbs stores both alongside the decisions about why each rule is there.
How system instructions work in the Gemini API
In the Gemini API, you pass system instructions as a separate field at the start of a request, distinct from the user's message. The model reads the system instructions first, then the user message. Instructions set there are not shown to the user and cannot be easily overridden by the user's input, which makes them the right place for rules about tone, format, scope or persona.
Google's API documentation covers the exact field names and how they behave across different model versions. Check those docs before assuming behavior transfers between models or API versions, since system instruction support can vary.
How Gem instructions differ from API system instructions
A Gem is a saved Gemini configuration you build in the Gemini interface. Its instruction field works similarly to the API's system instruction field: the model reads it before each user message. The practical differences are in setup. Gems are built and saved in a browser interface; API system instructions are passed in code.
If you are a developer calling the Gemini API directly, use the system_instruction parameter in your request. If you are building a Gem for non-technical users, write the instructions in the Gem editor. The rules for writing good instructions are the same either way.
For adjacent topics, see system prompt vs. user prompt for the distinction between what goes where, and system prompt examples for patterns you can adapt.
What to put in a system instruction
System instructions are for rules that should apply to every response, not just the current message. Good candidates:
- Role and scope: "You are a contract review assistant. You only answer questions about the contract the user provides."
- Tone and format: "Write in plain English. Use short paragraphs. Never use bullet points."
- What to refuse: "Do not give medical advice. When a question involves health decisions, suggest the user consult a doctor."
- Output structure: "Every reply must include a summary in the first sentence, then the detail."
- Handling uncertainty: "If you do not know, say so. Do not guess."
Keep system instructions to rules that truly apply everywhere. A fact that matters for one type of question but not others belongs in the user prompt when needed, not in the system instructions. Long instructions that contain a lot of situational material are harder for the model to follow consistently.
Write instructions the model can follow
Each instruction should describe an observable behavior. "Be helpful" is not an instruction the model can follow or fail. "When the user asks a question outside the stated topic, say which topic you cover and ask if they would like to continue" is something you can check.
Avoid instructions that conflict with each other. "Answer in detail" and "keep replies under 100 words" cannot both be followed. Decide which matters more and write only that one. If you need detail in some cases and brevity in others, specify the condition: "When the user asks for an explanation, give up to three paragraphs. For simple yes/no questions, reply in one sentence."
Add one worked example to the instructions when you have a format you care about. Show a realistic input and the exact output you want. This is often more effective than three additional rules.
Store your tested system instructions with their rationale
In fenbs, save each reviewed version of your system instruction as a Skill, with notes on the test inputs you used and what each rule is trying to prevent. When an instruction stops working or you need to hand the project to someone else, the rationale is there alongside the text. Create a free account and save your first prompt.
Create a free accountFree for one person · No credit card · Works with Claude, ChatGPT, Cursor and more
Test and refine your system instruction
Start with the cases you know the instruction needs to handle. Write three to five typical inputs and run them. Then test the edges: an input that is ambiguous, one that is outside the stated scope, one that is very short and one that is very long. Check that the output matches your instruction in each case.
When the model breaks a rule, read the instruction again before assuming it is a model error. Often the rule is ambiguous and the model found a valid interpretation you did not intend. Clarify the instruction rather than adding more rules on top of an unclear one.
How to do this with fenbs
- Create a free account and add a project for the application or workflow the Gemini integration supports.
- Save your system instruction text as a Skill in fenbs, with a short note on what it is for and the date you last tested it.
- Record each rule as a Decision and rules entry in the project: what the rule says, why it is there, and what prompted it.
- Keep a short list of your test inputs in the Skill notes so anyone revisiting the instruction knows what it was checked against.
- When you update the instruction, update the Skill and add a note on what changed and why.
For more on how models use different kinds of prompts, see prompt engineering and Gemini Gems. To compare Gemini with similar tools, Claude vs. Gemini covers the key differences.