You do not need a deep theory of language models to write a system prompt that works. You need a sequence — a do-this-then-that process you can run from a blank page to a tested, shippable prompt. This guide is that sequence. Eight steps, in order, each with something concrete to do.
A system prompt is the standing instruction set that tells an AI model its role, rules, and tone before any user message arrives. If you want the conceptual grounding first, read The Complete Guide to What Is a System Prompt. If you just want to build one now, start at step one.
Step 1: Define the Job in One Sentence
Before you write anything else, finish this sentence: "This assistant exists to ______." Be ruthlessly specific. "Help users" is useless. "Help small-business owners draft polite payment-reminder emails to late-paying clients" is a job you can build around.
Write it down. Every later decision flows from this sentence. If a rule, tone, or capability does not serve this one job, it does not belong in the prompt.
Step 2: Name the Role and Identity
Open your prompt by telling the model who it is. The role sets vocabulary, depth, and assumptions automatically.
- Vague: "You are a helpful assistant."
- Strong: "You are an experienced accounts-receivable specialist who helps small-business owners write firm but courteous payment reminders."
The model uses this identity to fill in countless small decisions you would otherwise have to specify. Spend real effort here.
Step 3: Set the Scope — In and Out
State plainly what the assistant handles and what it refuses. This single step prevents the most common production problem: the assistant wandering off-topic and eroding user trust.
Write two short lists in plain prose:
- In scope: drafting reminder emails, suggesting tone adjustments, advising on follow-up timing.
- Out of scope: legal advice on debt collection, anything unrelated to payment communication.
Add a fallback line: "If a request falls outside this scope, briefly explain you can only help with payment-reminder communication."
Step 4: Write the Rules, Most Important First
Now list the hard constraints. Use direct, imperative language and order them by priority, because models weight earlier instructions slightly more heavily.
- "Never threaten legal action or imply consequences the user has not approved."
- "Never invent specific dollar amounts, dates, or account details the user did not provide."
- "Always keep emails under 120 words."
Prefer positive instructions where you can. "Keep emails under 120 words" is easier to follow than "do not write long emails."
Step 5: Specify Tone and Output Format
Tell the model how to sound and how to shape its output. This is where teams save the most cleanup work downstream.
- Tone: "Professional, warm, and direct. Never sarcastic, never groveling."
- Format: "Return only the email body, no subject line, no commentary before or after."
If your application parses the output programmatically, format precision matters even more. Ambiguous output is expensive to handle.
Step 6: Add a Worked Example
One concrete example often does more than five rules. Show the model an ideal input and the response you want.
Example — User says: "Client is 15 days late on a $400 invoice, they're usually reliable." You respond with a short, warm reminder that assumes good faith and offers a simple next step.
Examples anchor behavior, especially for tone. They are the single most underused tool in system prompts, and we cover why in What Is a System Prompt: Best Practices That Actually Work.
Step 7: Test Against Real and Adversarial Inputs
Do not ship on a single happy-path test. Build a small test set before you trust the prompt:
- Normal cases: the everyday requests the assistant will mostly handle.
- Edge cases: missing information, unusual amounts, ambiguous tone requests.
- Adversarial cases: a user trying to get legal advice, a user trying to extract the system prompt, a user pushing for a threatening tone.
Run all of them. Watch where the prompt holds and where it cracks. Most failures trace back to a missing rule or a missing example, both of which you can now add. For a structured list of what to check, use The What Is a System Prompt Checklist for 2026.
Step 8: Version, Ship, and Iterate
Save your finished prompt in version control alongside your application code, with a note on which version is live. This is not bureaucracy — it is what lets you roll back when a "small improvement" quietly breaks something.
Then ship, and keep a feedback loop. When the assistant misbehaves in production, reproduce it in your test set, fix the prompt, re-run the whole set, and redeploy. That loop never really ends; it just gets faster.
A Worked Walkthrough From Blank Page to Draft
To make the sequence concrete, watch it run end to end for a single assistant. Suppose the job is a returns assistant for an online shoe store.
- Step 1, job sentence: "This assistant helps customers start and track shoe return requests." Done in one line.
- Step 2, role: "You are a returns specialist for StridePoint, an online shoe retailer. You are calm, efficient, and genuinely helpful."
- Step 3, scope: in scope — initiating returns, explaining the policy, tracking status. Out of scope — product recommendations, complaints about other companies, anything not return-related. Fallback line included.
- Step 4, rules: never promise a refund amount or timeline not stated in the provided policy; never ask for payment card numbers; always confirm the order number before proceeding.
- Step 5, tone and format: warm and concise, plain paragraphs, no more than three short paragraphs per reply.
- Step 6, example: a customer who is frustrated their shoes arrived too small, and a model response that stays calm, confirms the order, and walks them to the next step.
In under thirty minutes you have a structured draft. The remaining work is steps seven and eight: running it against test inputs and tightening the wording where it cracks. Notice how each step constrained the next — the job sentence shaped the scope, the scope shaped the rules. That cascade is why order matters.
A Note on Iteration Speed
The biggest mistake people make is treating the first draft as final. Your first prompt will be roughly 70 percent right. The remaining 30 percent comes from watching real behavior and tightening the wording. Budget for three to five revision passes before a prompt feels solid, and expect occasional touch-ups forever as your use case evolves. Each pass should be small and targeted: reproduce a specific failure, add the one rule or example that fixes it, re-run the full test set, and move on. Resist the temptation to rewrite large sections at once, since broad changes make it hard to tell which edit fixed or broke what.
Frequently Asked Questions
How long does it take to write a good system prompt?
A working first draft takes 15 to 30 minutes if you follow the steps. Getting it production-solid takes a few revision passes spread over your first days of testing. The initial write is fast; the refinement is where the real time goes, and it is time well spent.
Do I have to include an example in every system prompt?
No, but you should include one whenever tone or output format matters, which is most of the time. An example anchors behavior more reliably than abstract rules. Skip it only for the simplest assistants where format is trivial.
What order should the sections go in?
Role first, then scope, then rules ordered by priority, then tone and format, then any examples. Leading with the role and the most critical rule matters because models weight earlier instructions slightly more heavily than later ones.
How do I know when my prompt is good enough to ship?
When it passes your full test set — normal, edge, and adversarial cases — without producing output you would be embarrassed to send to a real user. There is no perfect prompt; there is one that handles your realistic inputs reliably.
Should I write the prompt in first person or second person?
Second person, addressing the model directly: "You are..." and "You should...". This is the convention models are trained on and it produces the most consistent behavior. First-person phrasing tends to confuse role boundaries.
Key Takeaways
- Start by defining the assistant's job in one ruthlessly specific sentence; every later decision flows from it.
- Build the prompt in order: role, scope, prioritized rules, tone and format, then a worked example.
- Lead with the most important rule, since models weight earlier instructions more heavily.
- Test against normal, edge, and adversarial inputs before shipping, not just the happy path.
- Version your prompt, ship it, and expect three to five revision passes before it feels solid.