GPT System Prompt: Write Rules and Use the Right Message Role

A GPT system prompt is the standing instruction you send in the "system" or "developer" message role at the start of an OpenAI API conversation. It applies to every user message in that session and tells the model what role to take, what rules to follow, and how to handle requests that fall outside scope.

The system message is the most reliable place to put your rules: it is read before any user message and carries the highest user-accessible weight in the conversation. Tools like fenbs store your approved system prompts as reusable skills so the tested version is always available without re-entry.

The message roles and what they do

The OpenAI chat completions API uses a messages array. Each item in the array has a role: "system", "developer", "user" or "assistant". The role determines how the model weights that message.

The "system" role is the original standing-instructions role. It has been the standard since the earliest GPT-4 API. The "developer" role is a newer addition, positioned above the "user" role in the model's priority order and intended for instructions from the application developer. In practice, both roles work well for system-level instructions. The key distinction is that "developer" messages are less easily overridden by user messages than "system" messages in some model configurations.

User messages in a conversation with GPT models cannot reliably override a well-written system message, but they can undermine vague or incomplete ones. A system message with clear rules and an explicit fallback is much harder to override than one that only describes a general role.

Writing effective system instructions

An effective GPT system prompt answers three questions: what role should the model take, what should it always and never do, and what should it do when a request is unclear or outside scope.

You are a customer support assistant for Acme Software.
Help users troubleshoot issues with Acme's desktop application.
Use US English. Keep responses under 200 words.
If the issue is not related to Acme Software, tell the user this assistant only supports Acme Software and offer to connect them to general support.
Do not speculate about pricing, roadmap or company policy.

Every rule in the prompt should be specific enough that you could tell whether the model followed it from reading the output. "Be helpful" is not a testable rule. "Keep responses under 200 words" is.

For detailed examples across more roles, see system prompt examples and ChatGPT prompts for work.

Testing instruction precedence

Once you have a draft, test it specifically to check that the instructions hold when a user message conflicts with them. These tests catch the most common failure mode: a system message that works for ordinary requests but breaks on edge cases.

• Send a user message that asks the AI to ignore its instructions. Check that the model refuses clearly rather than complying.
• Send a request just outside the defined scope. Check that the fallback instruction triggers correctly.
• Send an ambiguous request that could be interpreted as in-scope or out-of-scope. Check that the model handles it the way you intended.
• Send a formatting request that conflicts with your format rule. Check that the system-level format rule holds.

When an instruction fails those tests, the problem is usually in the system message, not in the model. A more specific rule, or an explicit example in the prompt, usually fixes the gap. See indirect prompt injection for the adversarial version of this problem.

Common patterns for work use

Effective GPT system prompts for work tend to share a few structural features. They start with the role in one sentence, follow with the positive rules the model should always apply, then the negative constraints, then the fallback. They use short, declarative sentences rather than paragraphs.

Add context that the model needs but the user should not have to provide every time: the company name, the product name, the audience, the format requirements. Move anything that changes per request to the user turn instead of the system message. If a rule applies to some requests but not others, it belongs in the user turn.

See context engineering vs prompt engineering for how to decide what goes in the system message and what should go in the broader session context.

Where rules get lost

The most common version of this problem is the approved system prompt that exists only in one developer's notes or a closed API playground session. When a new developer joins, when the product changes, or when the original person leaves, the approved version is gone and the next version is written from scratch without the reasoning that shaped the original.

A shared record that pairs each rule with the decision behind it prevents that loss. The rule and its reason travel together. When the situation changes, the reason shows whether the rule should change with it.

How to do this with fenbs

1. Create a free account and add a project for the GPT-based app or workflow you are configuring.
2. Draft the system prompt: role in one sentence, positive rules, negative constraints, fallback for out-of-scope requests.
3. Test the draft on your real inputs, including the precedence tests above.
4. Revise the prompt for each failure. Rerun the full test set after each change.
5. Add the tested prompt as a skill in fenbs. Record the reasoning behind any rule as a Decision.
6. Connect your AI apps over MCP from Integrations so the approved skill is readable in each session.

fenbs connects to ChatGPT over MCP in developer mode, so ChatGPT can read your skills and project context directly. Check which ChatGPT plans include developer mode on OpenAI's help pages, as plan requirements may change.