The hardest part of writing a system prompt is the blank box. You know what you want the model to do, vaguely, but staring at an empty field you are not sure whether to write a paragraph, a list of rules, or an essay about your company's values. So you either freeze or you dump everything you can think of into the box and hope for the best.
There is a faster, more reliable path. You do not need to master prompt theory before you produce something useful. You need a small set of prerequisites, a simple structure to fill in, and a tight loop of testing against real inputs. This article walks that path from zero to a working first result.
By the end you will have written a system prompt that does a specific job, tested it against inputs that matter, and understood enough of the why to keep improving it. The emphasis throughout is on shipping something real rather than reading about it, because the fastest way to learn what works is to watch your own prompt succeed and fail on inputs you actually care about.
What You Need Before You Start
A little preparation prevents most early frustration.
A specific job, written in one sentence
You cannot write a good system prompt for "be helpful." You can write one for "classify incoming support emails into billing, technical, or other." Before you touch the prompt, write a single sentence describing exactly what the model should do. If you cannot, you are not ready to write the prompt yet.
A few real example inputs
Collect five to ten actual inputs the system will face, including at least one messy or ambiguous one. These are your test cases. Without them you are tuning against your imagination, which always behaves better than reality.
A definition of a good output
Decide what success looks like before you start, so you can recognize it. For a classifier, the correct label. For a drafting assistant, a clear sense of tone, length, and what to avoid.
Access to the model the way you will ship it
Test in the same setting you intend to deploy. A prompt that behaves one way in a chat playground can behave differently through an API with different default settings. If you will ship through an application, do your testing there, or at least confirm the behavior matches before you trust the playground results. Small configuration differences cause surprises that are maddening to debug after launch.
A Simple Structure to Fill In
Rather than staring at a blank box, fill in four parts. This skeleton handles the large majority of real prompts.
Role
State who the model is and what it does in one or two sentences. "You are a support email classifier for an e-commerce company." This anchors everything that follows.
Rules and constraints
List the things the model must and must not do. Keep them concrete and few to start. You can always add more once you see where it goes wrong.
- Allowed actions and required behavior
- Hard prohibitions
- How to handle uncertainty or out-of-scope inputs
Output format
Specify exactly what the response should look like. If you need structured output, say so precisely: "Respond with only the category name, lowercase, nothing else." Vague format instructions produce vague formats.
A worked example
Show one input and the ideal output. A single clear example often does more than three paragraphs of instruction, because it demonstrates rather than describes. For more on assembling these pieces, see A Step-by-Step Approach to System Prompts.
Putting the skeleton together
Filled in, a first prompt might read as a short role sentence, a handful of bulleted rules, one line specifying the exact output format, and a single input-output example. That is it. It will look almost too simple, and that is the point. A prompt you can read in fifteen seconds is one you can debug, hand off, and trust. Complexity is something you add reluctantly, only when a real input proves you need it, never something you start with because it feels more thorough.
The Test-and-Tighten Loop
A first draft is never the finished prompt. The real work is the loop.
Run your example inputs
Feed each of your collected inputs to the model with the prompt and read the outputs. Do not skim. Look for the specific ways each output falls short of your definition of good.
Diagnose before you edit
When an output is wrong, figure out why before changing anything. Did the model lack a rule, misread an ambiguous input, or ignore an instruction buried in a wall of text? The fix depends on the cause. Knowing the common failure modes from 7 Common Mistakes with System Prompts (and How to Avoid Them) speeds this up.
Change one thing at a time
Make a single edit, re-run your inputs, and see if it helped without breaking something else. Changing five things at once leaves you unable to tell what worked. This discipline is the whole game.
Keep a record of what you tried
Jot down each change and whether it helped. Without notes you will circle back to edits you already rejected and lose track of why the prompt looks the way it does. A simple log, even a few lines per change, turns aimless tinkering into directed improvement and becomes the seed of the documentation a more mature prompt eventually needs.
Knowing When It Is Good Enough
Perfection is a trap; "reliably good on real inputs" is the goal.
Stop when it passes your cases
When the prompt produces good outputs across your example set, including the messy ones, you have a working first result. Ship it to a limited setting and watch real usage.
Keep the prompt small
Resist adding rules for problems you have not actually seen. A lean prompt is easier to understand and change later. You can grow it as real edge cases appear. When you are ready to go deeper, Advanced System Prompts: Going Beyond the Basics picks up where this leaves off.
Frequently Asked Questions
How long should my first system prompt be?
As short as possible while still doing the job, which often means a few sentences plus a short rule list and one example. Start lean and add only when a real input reveals a gap. Long first drafts hide bugs and are harder to debug.
Do I really need example inputs before I write the prompt?
Yes. Without real inputs you are testing against an imagined, well-behaved version of your users, and your prompt will look great until it meets reality. Even five real examples, including one messy one, will catch most early problems.
What if the model ignores one of my rules?
First check whether the rule is buried in a long block of text, since instructions get lost in walls of prose. Move it somewhere prominent, state it plainly, and re-test. If it still gets ignored, the rule may conflict with another instruction in the prompt.
When should I move past a basic prompt structure?
When the simple role-rules-format-example structure stops handling your cases, usually because you have many edge cases or need to coordinate tools and retrieved context. At that point, structured and layered approaches become worth the added complexity.
Key Takeaways
- The blank box is the hardest part; a fill-in structure removes it.
- Prepare a one-sentence job description, real example inputs, and a definition of good output.
- Fill in four parts: role, rules and constraints, output format, and a worked example.
- Run real inputs, diagnose failures before editing, and change one thing at a time.
- Stop when the prompt passes your cases, including the messy ones, then watch real usage.
- Keep the first prompt lean and grow it only as genuine edge cases appear.