You can read about system prompt theory all day and still freeze when you face a blank page. What unlocks the skill is seeing real prompts — what they were built to do, the specific choices inside them, and the moment something worked or broke. This article walks through five concrete use cases. For each, we look at the goal, the prompt approach, and the single decision that determined the outcome.
A system prompt is the standing instruction set that defines a model's role, rules, and tone. For the underlying concepts, see The Complete Guide to What Is a System Prompt. Here we stay concrete.
Example 1: A Customer Support Agent That Stays in Scope
The goal: a support assistant for a project-management SaaS that answers product questions and never wanders into competitor comparisons, legal advice, or unrelated topics.
The prompt opened with a specific role — "You are a support specialist for Tasksy, a project-management tool" — then defined scope explicitly: answer questions about Tasksy features, billing, and troubleshooting; for anything else, politely redirect. It included a fallback line for out-of-scope requests.
What made it work: the explicit redirect rule. Early versions without it answered general productivity questions and occasionally praised competitor tools. Adding "If asked about other products or topics outside Tasksy, briefly say you can only help with Tasksy and offer to connect them with the right resource" eliminated the drift entirely. Scope is not assumed; it must be stated.
Example 2: A Code Review Assistant With a Strict Output Format
The goal: an assistant that reviews pull requests and returns findings in a structured format the team's tooling could parse.
The prompt assigned the role of a senior engineer, listed what to check (security, performance, readability), and demanded a precise output: a numbered list where each item had a severity tag, a file reference, and a one-line fix. It included one example of a correctly formatted response.
What made it work: the example. Description alone produced inconsistent formatting that broke the parser. A single worked example showing the exact structure brought format compliance up sharply. This is the recurring lesson from What Is a System Prompt: Best Practices That Actually Work — examples beat adjectives for format every time.
Example 3: A Tutoring Bot That Refuses to Give Answers
The goal: a math tutor that guides students to solutions without handing them the final answer, even when asked directly.
The prompt's core rule was unusual: "Never state the final numerical answer. Guide the student with questions and hints until they reach it themselves." It included an example exchange of a student demanding the answer and the tutor warmly deflecting into a guiding question.
What made it work — and where it nearly failed: the example handling the demand. Without it, persistent students could pressure the model into just giving the answer, defeating the entire purpose. The example showing graceful refusal under pressure made the behavior hold. This is the same tone-under-pressure principle that prevents the failures in 7 Common Mistakes with What Is a System Prompt.
Example 4: A Brand Voice Writer
The goal: a marketing assistant that drafts social copy in a very specific brand voice — playful, concise, never corporate.
The prompt described the voice with a few adjectives but, crucially, included three short examples of on-brand copy and one example of off-brand copy labeled as "what to avoid." It also set a hard length limit.
What made it work: the contrast pair. Showing both an on-brand and an off-brand example gave the model a clearer target than positive examples alone. The model could triangulate the voice from the gap between them. The length limit, stated positively as "keep posts under 40 words," kept output tight.
Example 5: A Data Extraction Assistant Returning JSON
The goal: an assistant that reads messy customer emails and extracts structured data — order number, issue type, urgency — as clean JSON for a downstream system.
The prompt wrapped the input email in clear delimiters, specified the exact JSON schema with required keys, and added a rule for missing data: "If a field is not present in the email, set its value to null. Never guess." It returned only the JSON, no commentary.
What made it work: the "never guess, use null" rule plus the delimiters. Without the null rule, the model invented plausible-but-wrong order numbers when they were absent — a quietly dangerous failure in a data pipeline. Without delimiters, it sometimes treated instructions embedded in the email as commands. Both fixes were one line each.
The Pattern Across All Five
Look at what actually determined each outcome. It was rarely the role description and almost never the length. It was a single targeted decision: an explicit redirect, a worked example, a refusal-under-pressure demonstration, a contrast pair, a "never guess" rule. Strong system prompts are built from a few high-leverage choices, not from volume. When yours misbehaves, the fix is usually one precise addition, not a rewrite.
Example 6: An Internal Assistant That Cites Its Sources
The goal: an internal knowledge assistant that answers employee questions strictly from the company's documentation and refuses to speculate beyond it.
The prompt grounded the model hard: "Answer only using the documents provided below. If the answer is not in the documents, say 'I don't have that information in the available documentation' and stop." The reference documents were wrapped in delimiters, and the model was instructed to cite which document each fact came from.
What made it work: the explicit refusal-to-speculate rule combined with the citation requirement. Without the refusal rule, the model filled gaps with plausible but unverified claims about internal policy — exactly the kind of confident-but-wrong answer that erodes trust in an internal tool. The citation requirement gave employees a way to verify, which mattered more than the answer itself. This grounding pattern is the practical application of the knowledge component many prompts neglect.
Where it nearly failed: early versions cited documents that did not actually contain the cited fact. The fix was tightening the instruction to "cite only the document that directly states the fact" and testing against questions whose answers spanned multiple documents.
What These Examples Teach About Building Your Own
Across six examples, a few transferable habits emerge. Start every prompt with a specific role and a one-sentence objective. Add an explicit scope boundary so the assistant knows what to refuse. For anything factual, include a grounding or never-fabricate rule. Use delimiters whenever you inject data. And when a behavior matters — tone, format, or refusal — show it with an example rather than describing it. None of these requires a long prompt; they require the right few decisions. When your assistant misbehaves, resist rewriting everything and instead identify the single missing decision, the way each example here turned on one targeted choice.
Frequently Asked Questions
What is the most common high-impact addition across these examples?
A worked example. In the code reviewer, the tutor, and the brand writer, the single change that locked in correct behavior was showing the model a concrete example of the desired output rather than describing it. Examples consistently outperform abstract description.
Why do data extraction prompts need a "never guess" rule?
Because models are built to produce plausible output, and a missing order number can prompt them to invent a plausible one. In a data pipeline that fabricated value flows downstream as if it were real. An explicit instruction to return null for missing fields prevents this quietly dangerous failure.
Do these examples work on any AI model?
The principles transfer, but exact behavior varies by model. A redirect rule, a worked example, and delimiters help across the board, but the precise wording and how strictly the model obeys differ. Always test the specific prompt against the specific model you deploy.
How did the contrast pair help the brand voice writer?
Showing both an on-brand and an off-brand example let the model triangulate the target voice from the gap between them. Positive examples alone tell the model what to do; a labeled negative example also tells it what to steer away from, sharpening the target.
Can I combine techniques from several examples in one prompt?
Yes, and you often should. A real assistant might use an explicit scope rule, a worked output example, and delimiters for injected data all at once. The examples are isolated here for clarity, but the techniques compose well in production prompts.
Key Takeaways
- Explicit scope and redirect rules stop assistants from drifting off-topic; scope is never assumed.
- A single worked example fixes inconsistent output format more reliably than any description.
- For behaviors users will push against, like refusing to give answers, demonstrate the refusal under pressure with an example.
- Contrast pairs — one on-brand and one off-brand example — sharpen tone targets better than positive examples alone.
- In data pipelines, a "never guess, use null" rule plus delimiters prevents fabricated values and injection through input.