System Prompt vs. User Prompt: What Goes in Each?
A system prompt sets standing instructions that apply to every message. A user prompt is the specific request for this session. Here is what belongs in each, with paired examples.
Updated 5 min read
A system prompt contains the standing instructions that apply to every message in a session: how the assistant behaves, what it does and does not do, the format of its replies. A user prompt is the specific request you make in this conversation, right now. The distinction matters because the same rule written in a system prompt applies once and reliably; rewritten in every user prompt it can drift, get forgotten, or conflict with earlier versions.
Understanding which kind of instruction belongs where makes your prompts shorter, your AI outputs more consistent, and the rules easier to maintain. Tools like fenbs store your approved system prompts as reusable Skills, so the rules your team has tested are available to any connected assistant without being retyped.
| System prompt | User prompt | |
|---|---|---|
| Purpose | Standing instructions that apply to every message | The specific request for this session or turn |
| When it is read | Once, before every user message | Each time the user sends a message |
| Examples | Tone, format, scope rules, persona, what to refuse | A question, a document to analyze, a task to complete |
| How often it changes | Rarely; when the rules change | Every message |
| Who writes it | The developer, operator, or team lead | The person or process making the request |
What a system prompt does
The system prompt is the configuration layer. It tells the model what kind of assistant it is, what topics it covers, how to format its output, and what it should refuse. These rules apply to every response in the session without the user having to repeat them.
Think of the system prompt as the job description for this instance of the assistant. A customer support assistant, a legal research assistant and a coding assistant can all run on the same model, but with different system prompts each behaves differently and is appropriate for different tasks.
System prompts are typically set by the operator — the developer building the application or the team lead configuring a shared tool. In some tools they are visible to the user; in others they are not. In the Gemini API and the Anthropic API they are passed as a separate field; in ChatGPT's custom GPTs they are the instruction field.
What a user prompt does
The user prompt is the specific request in this session: a question, a document to review, a task to complete, or a follow-up on the previous message. It is one-time. Once you have your answer, the prompt's job is done.
User prompts can include context that only applies to this request: the specific document to summarize, the project the question is about, or the audience for this particular piece of writing. That context does not need to be in the system prompt because it changes from request to request.
Paired examples: the same task, handled each way
Say you are building a writing assistant that always replies in plain English, writes for a non-technical audience, and never uses bullet points.
In the system prompt:
You are a writing assistant. Write in plain English. Your audience is not technical — avoid jargon. Never use bullet points. Keep every paragraph to three sentences or fewer.
In the user prompt:
Rewrite the following paragraph to be clearer and shorter: [paragraph text here]
The user prompt contains only what changes from request to request: the instruction (rewrite) and the content (the paragraph). The system prompt handles everything that stays the same: the style rules, the audience, the format constraint. If you change the document, you change the user prompt. The style rules never move.
What goes in the system prompt
- Role and persona: "You are a contract review assistant for a US law firm."
- Scope rules: "Only answer questions about the document the user provides. If asked about other topics, redirect."
- Tone and format: "Reply in formal English. Use numbered lists only for step-by-step processes."
- What to refuse: "Do not provide investment advice. When asked, say that financial decisions require a licensed advisor."
- Handling uncertainty: "If you are not sure, say so. Do not guess."
- One worked example, when the output format is specific.
What goes in the user prompt
- The specific task: "Summarize the risks in section 4."
- The content to work with: the document, the data, the question.
- Context specific to this request: "This is for a client who has not seen a contract before."
- Variations from the default: "For this one, reply in bullet points." (Overrides the system prompt rule for this message.)
When a user prompt overrides a system prompt rule for a single reply, that override applies only to that message. The system prompt rule comes back for the next one.
Store approved system prompts as reusable Skills
In fenbs, save your tested system prompts as Skills with notes on what each rule is for and what was tested. Any connected AI assistant can list and read the Skills, so your team starts every session from the same reviewed starting point rather than rewriting instructions. Start with 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
When the line blurs
Not every tool has a distinct system prompt field. Some chat interfaces pass everything as user messages and use structural markers to separate standing instructions from the actual request. Some agent frameworks include the system prompt in the first user turn. The underlying distinction still holds: standing rules belong together and do not repeat, while request-specific content varies.
In tools where the system prompt is visible to the user — or where users can read or influence it — indirect prompt injection becomes a consideration. External data the assistant processes could contain instructions designed to override the system prompt.
How to do this with fenbs
- Create a free account and add a project for the use case you are building.
- Write the standing rules as a system prompt and save it as a Skill in fenbs, with notes on what each rule prevents.
- Record key decisions — why a rule exists, who approved it, what prompted it — as Decisions and rules in the project.
- Connect your AI assistant to fenbs over Integrations so it can read the Skills at the start of a session.
- When a rule changes, update the Skill and note the reason so the history of decisions is preserved.
When a teammate changes a system prompt rule without knowing why it is there, they may undo a fix that prevented a real problem. Record the reasoning in Decisions and rules so the history travels with the prompt.
For examples of system prompts across different tools and use cases, see system prompt examples. For the broader practice of writing effective prompts, see prompt engineering.