A system prompt is the instruction a language model reads before it sees anything the user types. It sets the role the model plays, the rules it follows, and the shape of its answers. If the user message is the question, the system prompt is the standing brief that decides how every question gets answered.
You do not need a course or a framework to write your first one. You need to understand a handful of moving parts and avoid two or three predictable mistakes. The goal of this guide is narrow and practical: get you from a blank box to a system prompt that produces reliable, useful output, fast — and leave you knowing how to tell whether it actually works.
This is the zero-to-first-result path. Once you have a working prompt, the deeper material on structure and measurement will make a lot more sense, because you will have something concrete to apply it to.
What You Need Before You Start
A first system prompt has only a couple of real prerequisites, and they are smaller than people assume.
Access to a model with a system role
Any current chat model that distinguishes a system message from a user message will do. Most APIs and many chat interfaces expose this. If you can place text in a "system" slot separate from the conversation, you are equipped.
A specific job in mind
The single biggest predictor of a good first prompt is a narrow, concrete task. "Be a helpful assistant" produces mush. "Summarize support emails into three bullet points and a suggested priority" produces something you can evaluate. Pick a task you can describe in one sentence and judge in five seconds.
The Anatomy of a Working First Prompt
A solid starter prompt has four parts. You do not need more than these to get a real result.
- Role. Tell the model who it is. "You are a support triage assistant for a B2B software company." This anchors tone and assumptions.
- Task. State the job plainly. "Read the customer message and produce a summary and a priority level."
- Format. Pin the output shape. "Respond with a one-sentence summary, then a priority of low, medium, or high." Format is where most first prompts win or lose.
- Boundaries. Name what to do when things go sideways. "If the message is unclear, ask one clarifying question instead of guessing."
Write those four, in that order, in plain language. That is a complete first system prompt. Resist the urge to add ten more rules before you have seen it run — premature complexity is the most common way first prompts go wrong, as the common mistakes guide details.
Your First Iteration Loop
A system prompt is never right on the first try, and that is fine. The skill is the loop, not the first draft.
Run it on real inputs
Feed it five or six actual examples, including at least one messy one. Do not test only the clean, obvious case — the messy input is where you learn whether your boundaries hold.
Read the failures, not the successes
When an output is wrong, ask which of the four parts failed. Wrong tone is a role problem. Wrong shape is a format problem. A confident answer to an ambiguous input is a boundaries problem. Mapping each failure to a part tells you exactly what to edit.
Change one thing at a time
Edit a single part, rerun the same examples, and see if the failure moved. Changing three things at once means you learn nothing about which change helped. This discipline is the whole game, and the step-by-step guide expands it into a full workflow.
Knowing When It Is Good Enough
Beginners either ship too early or polish forever. A simple bar settles it.
The repeatability test
Run your prompt on the same handful of inputs three times. If it produces consistent, acceptable output each time, it is good enough to use. If it wobbles — sometimes right, sometimes not — it is too loose and needs a tighter rule on whatever varied.
The hard-case test
Throw your two nastiest realistic inputs at it: the ambiguous one and the out-of-scope one. If it handles both sanely — clarifying or declining rather than confidently making things up — your boundaries are doing their job. If you want to confirm it more rigorously later, the metrics guide shows how to turn these checks into tracked numbers.
Where to Go Next
Once you have a working prompt, three moves level you up without overwhelming you.
- Save your test inputs. The handful of examples you used become your first regression set. Rerun them whenever you change the prompt.
- Learn the prompt-versus-retrieval split. Keep changing facts out of the system prompt; the best practices guide explains why.
- Read the framework. When one prompt becomes several, a repeatable framework keeps them consistent.
Start narrow, get one prompt working, and build outward from something real. That beats reading ten guides before writing a single line.
A Worked First Example
To make this concrete, here is what a first prompt looks like in practice for a simple support-triage task. Notice how it maps directly onto the four parts and stays short.
The role line establishes context: a triage assistant for a B2B software company. The task line states the job: read a customer message, summarize it, and assign a priority. The format line pins the shape: a one-sentence summary followed by a priority of low, medium, or high. The boundaries line handles the messy case: if the message is unclear, ask one clarifying question rather than guessing a priority.
That is the entire prompt — four short sections, well under 200 words. When you run it on a clean billing question, you get a tidy summary and a sensible priority. When you run it on a vague two-word complaint, the boundaries line earns its place: instead of inventing a priority, the model asks what the customer needs. That single behavior is the difference between a prompt that looks fine in a demo and one that holds up on real traffic.
If the priority levels come back inconsistent across runs on the same input, that is your signal to tighten the format section — perhaps by defining what each priority level means. Changing only that section and rerunning your examples tells you immediately whether the fix worked, which is the loop in miniature.
Frequently Asked Questions
Do I need to know how to code to write a system prompt?
No. A system prompt is plain language, and many chat interfaces let you set one without any code. Coding only becomes relevant when you want to automate testing or wire the prompt into an application. The writing itself is a language task, not a programming one.
How long should my first system prompt be?
Short. Cover the four parts — role, task, format, boundaries — in a few sentences each and stop. A first prompt under 200 words is usually plenty. Length should grow only in response to a failure you actually observed, not in anticipation of one.
Why does the model ignore some of my instructions?
Usually because the instruction is vague, buried among too many others, or contradicts another clause. Newer models follow clear instructions closely, so when one is ignored, the fix is almost always to make it sharper and remove whatever competes with it.
Should facts and data go in the system prompt?
Keep anything that changes — prices, dates, inventory — out of the system prompt. Put stable behavior there and supply changing facts through the user message or a retrieval step. Baking volatile data into the prompt guarantees it goes stale.
How do I know if my prompt is actually working?
Run it on the same realistic inputs several times. If the output is consistent and acceptable, including on your hardest cases, it works. If it varies or mishandles edge cases, it needs a tighter rule on whatever broke. Repeatability on real inputs is the test.
Key Takeaways
- A system prompt sets the model's role, task, format, and boundaries before any user input.
- Start with a narrow, one-sentence task you can judge instantly.
- Write the four parts plainly and resist adding rules before you have seen it run.
- Iterate by mapping each failure to a part and changing one thing at a time.
- It is good enough when it produces consistent, sane output on your real and hardest inputs.