System Prompt Examples: Reusable Templates for Reliable AI Assistants

Overview

A system prompt sets the assistant’s operating context before a user sends a request. It can define the assistant’s purpose, preferred behavior, limits, response format, escalation rules, and relationship to external tools or retrieved information.

A useful system prompt is not simply a long list of instructions. It is a compact operating specification that helps the model make consistent decisions across many conversations. The best prompt templates are specific enough to guide behavior but flexible enough to handle legitimate variations in user input.

For production LLM application development, a system prompt should work alongside application code, access controls, validation, retrieval, and monitoring. It should not be treated as a substitute for enforcing permissions or validating sensitive operations in code. For a broader review of evaluation, monitoring, and cost considerations, see the LLM application reliability checklist.

Across most use cases, a dependable system prompt answers five questions:

• What is the assistant responsible for?
• What information may it use?
• What should it do when information is missing or uncertain?
• What actions or topics are outside its scope?
• What format should the final answer follow?

Template structure

A practical system prompt can be organized into the following blocks. You do not need every block for every assistant, but the structure makes omissions easier to spot.

1. Role and purpose

State what the assistant does and who it serves. Avoid vague descriptions such as being helpful with anything. Instead, describe the business or technical task it is expected to support.

Role: You are a support assistant for a software product.
Purpose: Help users understand documented product behavior and resolve common setup issues.

2. Priority of instructions

Explain which instructions should guide the response when requirements conflict. A concise hierarchy can reduce ambiguity, especially when the assistant receives retrieved text, tool results, or user-provided instructions.

Follow these priorities:
1. Follow application and safety constraints.
2. Follow this system prompt.
3. Use trusted context supplied by the application.
4. Follow the user request when it is within scope.

This wording should be adapted to your application’s actual architecture. Do not assume a prompt can enforce security boundaries that are not implemented elsewhere.

3. Operating procedure

Describe the steps the assistant should take. For example, it might identify the request, check available context, ask for missing details, and then produce an answer. Procedures are especially useful for workflow assistants and tool-using systems.

Before answering:
- Identify the user’s goal.
- Check whether the required information is available.
- If a key detail is missing, ask one focused question.
- Do not imply that an action was completed unless the application confirms it.

4. Boundaries and uncertainty

State what the assistant should refuse, redirect, or qualify. Include a clear rule for uncertainty. A reliable assistant should distinguish between known information, supplied context, and reasonable but unverified assumptions.

Use only the provided documentation for product-specific claims.
If the answer is not supported by that documentation, say that the information is unavailable and suggest the next appropriate step.
Do not invent account details, system status, citations, or completed actions.

5. Output contract

Define the expected format. Structured output prompts are easier to integrate when the application needs to parse the response, but the schema should be validated in code as well.

Return valid JSON with these fields:
{
  "answer": "string",
  "needs_clarification": "boolean",
  "escalate": "boolean"
}
Do not include additional fields.

6. Escalation and handoff

Tell the assistant when to stop trying to solve the request. Include the information a handoff should contain, such as the user’s issue, relevant troubleshooting steps, and missing details. This is more useful than a general instruction to escalate difficult cases.

How to customize

Start with the smallest prompt that can support the task, then add rules in response to observed failure modes. Large prompts can hide contradictions and make maintenance harder. Treat the prompt as a versioned product artifact rather than a one-time piece of copy.

Define the source of truth

For a retrieval-augmented application, specify how the assistant should use retrieved content. For example, instruct it to prioritize the supplied context for product-specific answers, identify when the context does not answer the question, and avoid presenting unrelated passages as evidence. A prompt cannot fix poor retrieval, so pair these instructions with retrieval evaluation. The production-ready RAG tutorial provides a related framework for building retrieval pipelines.

Separate behavior from data

Keep stable behavior in the system prompt and pass changing information as clearly labeled application context. This may include account details, product documentation, order status, or retrieved passages. Separating the two makes updates easier and reduces the risk of embedding stale operational data in a prompt.

Use examples selectively

Few-shot prompting examples are helpful when the desired behavior is difficult to express with rules alone. Good examples demonstrate realistic input, the expected reasoning boundary, and the exact output shape. Include edge cases rather than many near-identical examples. Remove examples that encourage the model to copy irrelevant wording or expose internal notes.

Make tool behavior explicit

If the assistant can call tools, define when a tool is appropriate, what inputs it requires, and what the assistant should say after a successful or failed call. The application should still validate tool arguments and permissions. A useful instruction is: do not claim that a tool ran unless a tool result is present in the conversation or application state.

Test against representative failures

Build a small evaluation set containing normal requests, ambiguous requests, unsupported questions, malformed inputs, prompt injection attempts, and tool failures. Compare responses against criteria such as factual grounding, format compliance, appropriate escalation, and unnecessary verbosity. Prompt engineering is most effective when changes are tested against the same cases rather than judged from one conversation.

Examples

Customer support assistant

You are a customer support assistant for a documented software product.

Your responsibilities:
- Explain documented features and troubleshooting steps clearly.
- Ask for the minimum missing detail needed to proceed.
- Use only the product context supplied by the application for product-specific claims.

Boundaries:
- Do not invent account information, outages, refunds, or policy details.
- Do not request passwords, secret keys, or full payment credentials.
- Escalate billing disputes, suspected account compromise, and unresolved technical issues.

Response format:
1. Direct answer or next step.
2. Short numbered instructions when troubleshooting is required.
3. Escalation note when the issue is outside scope.

Research assistant

You are a research assistant that summarizes supplied sources.

For each response:
- Identify the question being answered.
- Separate source-supported findings from interpretation.
- Note important limitations or missing evidence.
- Do not create citations, quotations, or numerical claims that are not present in the supplied sources.

If the sources do not answer the question, say so directly and list the additional information needed.

Coding assistant

You are a coding assistant for maintainable application development.

Before proposing code:
- Identify the language, runtime, framework, and relevant constraints when available.
- State assumptions that materially affect the solution.
- Prefer small, testable changes over unnecessary rewrites.

When providing code:
- Include error handling appropriate to the example.
- Do not include real secrets or recommend placing secrets in source code.
- Explain how to test the change and mention likely edge cases.
- If a requirement is ambiguous, ask a focused question or present clearly labeled alternatives.

Data extraction assistant

You extract fields from user-supplied text.

Return only valid JSON matching the supplied schema.
Use null when a field is absent or cannot be determined.
Do not infer sensitive or identifying details that are not explicitly present.
Preserve dates, identifiers, and quoted text exactly unless normalization rules are provided.
If the input is unreadable or outside the expected document type, set "status" to "needs_review".

When to update

Review a system prompt whenever the assistant’s task, tools, data sources, or output contract changes. It should also be revisited when evaluations reveal recurring errors. Useful update triggers include:

• A new tool, workflow, or permission boundary is introduced.
• The application adds a new document source or changes retrieval behavior.
• Users regularly misunderstand the assistant’s scope or escalation path.
• Structured responses fail validation or omit required fields.
• The model, API configuration, or message-handling flow changes.
• A prompt injection or data-handling weakness is discovered.
• Support, research, or coding workflows change in the surrounding application.

Keep a short changelog for each prompt version. Record the reason for the change, the evaluation cases affected, and any trade-offs observed. Re-run representative tests before releasing the new version. For a wider pre-release review, use the prompt engineering checklist before shipping an AI feature.

To apply this guide, choose one assistant workflow and write a first version using the role, procedure, boundaries, output, and escalation blocks. Test it with ordinary and failure-oriented examples. Then remove rules that do not change behavior, clarify rules that produce inconsistent results, and move security-critical enforcement into application code. A system prompt becomes reliable through this cycle of explicit design, testing, and maintenance—not through length alone.