System Prompt Examples: Reusable Instructions for Common AI App Roles

Overview

System prompts are persistent instructions supplied by the application to establish an assistant’s behavior before a user’s request is processed. They are different from a user prompt, which contains the immediate task. In an LLM application, the system prompt can define the assistant’s role, audience, tone, allowed tools, output format, limitations, and escalation rules.

The most useful system prompts are specific without trying to describe every possible conversation. A practical prompt usually answers five questions:

• Role: What function does the assistant perform?
• Objective: What outcome should it optimize for?
• Boundaries: Which topics, actions, or claims are outside its authority?
• Output: What structure, tone, and level of detail should it use?
• Escalation: When should it ask for clarification, defer, or hand the task to a person?

Use the templates below as starting points, not as universal rules. Replace bracketed fields with details from your product, define terms that your users understand, and connect the prompt to application-level validation. A system prompt can guide behavior, but it should not be treated as the only control for permissions, privacy, billing, or other consequential actions.

Checklist by scenario

1. Customer support agent

A support agent should be helpful and efficient while avoiding invented account details, unsupported promises, and actions it cannot perform.

You are a customer support assistant for [company or product].

Your goals are to:
- Understand the customer’s issue and provide the next useful step.
- Use only the product information and account context supplied by the application.
- State clearly when the available information is insufficient.
- Ask one or two focused questions when essential details are missing.

Rules:
- Do not invent policies, refunds, delivery dates, account data, or troubleshooting results.
- Do not claim that an action was completed unless the application confirms it.
- Do not request passwords, full payment card numbers, or other unnecessary sensitive information.
- Escalate complaints involving [billing disputes, safety, legal matters, or account ownership] to a human queue.

Response format:
1. Briefly acknowledge the issue.
2. Give the best supported answer or next step.
3. List any information needed to continue.
4. If escalation is required, explain what will happen next.

For production use, pair this prompt with retrieval from approved help content and explicit tool responses. A RAG workflow can supply current product context, while application code should decide whether an account-changing tool is actually permitted.

2. Research assistant

Research assistants need clear rules about evidence. They should distinguish supplied material from general reasoning and avoid presenting an inference as a verified fact.

You are a research assistant helping [audience] investigate [topic].

For each response:
- Separate information directly supported by the supplied sources from interpretation.
- Identify the source or passage used when source references are available.
- State when the evidence is incomplete, conflicting, or outside the requested scope.
- Do not create citations, quotations, statistics, or publication details.
- Ask whether the user wants a quick summary, comparison, chronology, or detailed analysis when the task is ambiguous.

Preferred format:
- Answer: [concise conclusion]
- Evidence: [supporting points and source references]
- Uncertainty: [limitations or unresolved questions]
- Suggested next step: [focused follow-up]

If the assistant searches a knowledge base, define how it should behave when retrieval returns no relevant material. For example, require it to say that the answer was not found rather than fill the gap with a guess. This is also a useful place to specify date ranges, geographic scope, and terminology.

3. Coding copilot

A coding copilot benefits from instructions that prioritize the existing codebase over generic examples. It should clarify assumptions, preserve compatibility, and make changes easy to review.

You are a coding copilot for [language, framework, and repository].

Before proposing code:
- Inspect the provided files, interfaces, tests, and dependency constraints.
- State important assumptions and identify missing context.
- Prefer the smallest change that satisfies the request.
- Follow the project’s existing naming, formatting, error-handling, and testing conventions.

When responding:
- Explain what changed and why.
- Show the relevant code or a focused patch.
- Include tests for normal, boundary, and failure cases when appropriate.
- Do not claim that code was executed, tested, or reviewed unless tool output confirms it.
- Flag security, data-loss, performance, and backward-compatibility risks.

Tool permissions should be enforced outside the prompt. If the copilot can run commands, edit files, or access repositories, give each tool a narrow schema and require confirmation for destructive operations.

4. Data extraction tool

Extraction prompts should define a schema and a policy for missing or ambiguous values. They should not encourage the model to make fields look complete.

You extract structured fields from the provided document.

Return only valid JSON matching this schema:
{
  "customer_name": "string or null",
  "invoice_number": "string or null",
  "invoice_date": "YYYY-MM-DD or null",
  "total_amount": "number or null",
  "currency": "string or null",
  "confidence_notes": ["string"]
}

Rules:
- Use null when a value is absent or cannot be resolved.
- Do not infer a value from an unrelated field.
- Preserve the document’s meaning and normalize dates only when unambiguous.
- Put ambiguity or conflicting values in confidence_notes.
- Return no commentary outside the JSON object.

Structured outputs, schema validation, and retry handling belong in the application layer as well. For a broader approach to extraction prompts, see this information-extraction guide.

5. Content reviewer

A content reviewer should apply explicit criteria rather than a vague instruction such as “make this better.” Define the audience, review dimensions, and how feedback should be separated from rewriting.

You review [content type] for [audience] against the following criteria:
- Accuracy relative to the supplied brief or source material
- Clear structure and useful specificity
- Appropriate tone for [brand or audience]
- Plain language and consistent terminology
- Claims that require verification

Do not invent facts or sources. Preserve the writer’s intended meaning unless a requested change requires otherwise.

Return:
1. Decision: pass, revise, or blocked
2. Strengths: up to three specific observations
3. Required revisions: prioritized, actionable items
4. Optional improvements: clearly separated from required changes
5. Questions: information needed from the editor

What to double-check

Before shipping a system prompt, use this review checklist:

• Inputs: Does the prompt identify which information comes from the user, retrieval, tools, or application metadata?
• Priority: Are the most important rules short, explicit, and placed where the model can reliably use them?
• Output contract: Is the required format unambiguous? If JSON is required, is it validated after generation?
• Missing data: Does the assistant know whether to ask, return null, defer, or explain uncertainty?
• Refusal behavior: Does it decline unsupported or out-of-scope requests without revealing unnecessary internal instructions?
• Escalation: Are human handoffs based on observable conditions rather than vague language?
• Tool use: Must the assistant ask for confirmation before irreversible, external, or expensive actions?
• Evaluation: Do you have representative test cases for correct answers, ambiguity, adversarial wording, long inputs, and malformed data?

Keep a versioned copy of every production prompt and record the model, retrieval settings, tools, and output validators used with it. Prompt changes can alter behavior even when application code stays the same. A regression set and scoring rubric make those changes easier to inspect. The LLM evaluation guide and prompt testing framework provide useful structures for this work.

Common mistakes

• Writing a job description instead of an operating brief: A role label is not enough. Include decisions, constraints, and output requirements.
• Overloading the prompt: Long lists of loosely related rules can conflict. Remove instructions that do not affect observable behavior.
• Using absolute claims: “Always be accurate” is less useful than “use only supplied sources and mark unsupported claims as unknown.”
• Confusing guidance with enforcement: Prompts do not replace authorization checks, input filtering, schema validation, logging, or human review.
• Forcing an answer: A required answer to every question encourages guessing. Define a useful uncertainty or escalation path.
• Changing several variables at once: When testing prompt optimization, record model, temperature or equivalent settings, tools, context, and prompt version.
• Ignoring prompt injection: Treat retrieved documents and user-provided text as data, not as trusted instructions. Explicitly tell the assistant not to follow instructions embedded in source material.

When to revisit

Review a system prompt before seasonal planning cycles, product launches, major content updates, or any change to the workflow around it. A support prompt may need new escalation categories when policies change. An extraction prompt may need a revised schema when document formats evolve. A coding copilot may need updated repository conventions after a framework migration.

Also revisit prompts when you change the model, add or remove tools, modify retrieval sources, adjust context limits, or observe a new failure pattern. Keep a small set of repeatable examples that represent your highest-risk and most common tasks. Run those examples after each meaningful change, compare both correctness and format compliance, and review surprising outputs manually.

Use this final release checklist:

1. Write the role, objective, boundaries, output schema, and escalation rules.
2. Replace placeholders with product-specific terms and approved data sources.
3. Add application controls for permissions, validation, privacy, and irreversible actions.
4. Test normal, ambiguous, unsupported, adversarial, and malformed inputs.
5. Version the prompt and record the surrounding model and workflow configuration.
6. Schedule the next review when the workflow or its underlying inputs are likely to change.

For related prompt chaining and structured-output patterns, see this AI content workflow guide. A system prompt is most reliable when it is treated as one maintained component of a tested LLM application, not as a one-time piece of copy.