System Prompt Examples: Reusable Instructions for Reliable AI Assistants

Overview

A system prompt sets the operating instructions for an AI assistant before it responds to a user. It can establish the assistant’s purpose, explain what information it should prioritize, define the boundaries of its work, and specify how results should be presented. In an AI development workflow, the system prompt is not a complete application specification, but it is an important control layer between the model and the surrounding product.

Good system prompts are specific without trying to describe every possible conversation. They make important decisions explicit: what the assistant is responsible for, what it must not claim, when it should ask a question, when it should use a tool, and what format it should return. These instructions make LLM prompting easier to test because the expected behavior can be evaluated against concrete criteria.

A useful prompt should also be treated as versioned workflow logic. If the assistant’s data sources, tools, audience, or output requirements change, the prompt should be reviewed alongside the application code and evaluation cases. For broader testing guidance, see this LLM evaluation checklist.

Template structure

The following structure works as a starting point for many prompt templates. Remove sections that do not apply rather than filling every section with vague instructions.

You are [role] for [audience or product].

Purpose:
- [Primary task]
- [Important outcome]

Context and source rules:
- Use [approved sources, retrieved context, or user-provided information].
- Distinguish known information from assumptions.
- If the required information is missing, [ask a question or state the limitation].

Process:
1. [First step]
2. [Second step]
3. [Validation or review step]

Constraints:
- [Safety, privacy, scope, or business constraint]
- Do not [prohibited behavior].
- Do not invent facts, citations, tool results, or completed actions.

Tools:
- Use [tool] when [condition].
- Before using it, verify [required input].
- After using it, report [relevant result or limitation].

Output format:
- Return [format, schema, or section order].
- Include [required fields].
- If a field is unknown, use [null, an explicit label, or a clarification request].

Uncertainty and refusal:
- If the request is outside scope, explain the limitation and offer [safe alternative].
- If instructions conflict, prioritize [defined order of authority].

This layout separates purpose from implementation details. It also gives developers clear places to add structured outputs, tool conditions, and failure behavior. For extraction tasks, include field definitions and validation rules. For conversational assistants, include escalation and clarification behavior. For retrieval-augmented applications, define how retrieved passages should be used and what the assistant should do when they do not answer the question. The RAG workflow guide provides a useful companion framework for that scenario.

How to customize

Define the role through responsibilities

“You are a helpful assistant” is too broad to guide a production workflow. Replace it with a responsibility such as “You review support tickets for missing information and propose a response for a human agent.” State what success looks like and what is outside the assistant’s role.

Turn preferences into observable rules

Words such as “accurate,” “professional,” and “concise” can be useful, but they are difficult to test alone. Add observable instructions: use headings, keep the response under a specified length when appropriate, preserve identifiers exactly, or return a defined JSON object. Constraints should describe behavior rather than simply express a desired tone.

Separate trusted context from model judgment

Tell the assistant which information it may rely on. A research assistant might use only supplied documents and clearly label unanswered questions. A support assistant might use the current account record but not infer billing details that are absent. This distinction reduces the risk of confident answers based on unsupported assumptions.

Design tool use as a decision

Do not merely list available tools. Explain when each tool is appropriate, what inputs it requires, and what the assistant should do if it fails. For example, a coding assistant may inspect a repository before proposing a change, while a data assistant may validate a date range before querying a database. Tool instructions should not imply that an action occurred unless the application confirms it.

Use structured outputs where downstream systems depend on them

If another service parses the response, specify the fields, types, allowed values, and missing-value behavior. Application-level schema validation is still important; a prompt can request valid JSON, but the calling system should validate and handle malformed or incomplete output.

Add examples selectively

Few-shot prompting examples are useful when the desired behavior is difficult to express as a rule, such as classifying ambiguous requests or preserving a particular transformation pattern. Use representative examples that cover edge cases, not a long collection of ordinary cases. Keep examples consistent with the current instruction set.

Examples

Research assistant

You are a research assistant who helps analysts summarize supplied documents.
Use only the provided documents unless the user explicitly supplies another source.
Separate sourced claims from interpretation. If the documents do not answer a question, say so.
Return: a short answer, supporting passages or document labels, unresolved questions, and assumptions.
Do not invent citations, publication details, or quotations.

Coding assistant

You are a coding assistant working inside an existing software project.
Before suggesting a change, identify the relevant files, interfaces, and likely dependencies from the context provided.
Preserve existing conventions unless a change is requested. Explain assumptions and flag security, compatibility, or testing concerns.
Return: proposed change, affected files, implementation notes, and tests to run.
Never claim that code was executed, tested, committed, or deployed unless the tool result confirms it.

Customer support assistant

You draft customer support replies for human review.
Use the account and policy information provided in the conversation. Do not guess eligibility, delivery status, refunds, or account details.
Ask for the minimum missing information needed to proceed. Escalate requests involving exceptions, disputes, or sensitive account changes.
Return a concise draft reply followed by an internal note listing missing information or escalation reasons.

Structured data extractor

You extract fields from the supplied text.
Return valid JSON with exactly these keys: name, date, amount, currency, and confidence.
Use null when a value is absent or ambiguous. Preserve the source wording for names and do not calculate missing amounts.
Confidence must be one of: high, medium, low. Include no commentary outside the JSON object.

These examples are deliberately short. In a real implementation, connect each prompt to representative test cases, including incomplete inputs, conflicting instructions, malformed documents, and requests outside the assistant’s scope. A documented scoring rubric makes prompt optimization more reliable than judging isolated outputs. See the prompt testing and evaluation framework for a practical approach.

When to update

Revisit a system prompt whenever the assistant’s job, inputs, tools, or audience changes. A prompt should be reviewed when a new data source is introduced, a tool gains or loses permissions, an output schema changes, or users begin asking for work outside the original scope. Changes in the publishing or content workflow are also a reason to update prompts used for briefs, reviews, metadata, or content refreshes. The AI content automation workflow covers how prompts and review checkpoints can fit together.

Maintain prompts as versioned artifacts. Record the purpose of each change, retain a small regression set, and compare the new version with the previous one on accuracy, format compliance, useful refusals, and unnecessary refusals. When a prompt repeatedly needs exceptions, revise the structure rather than adding another vague instruction.

To put this into practice, choose one assistant and document its role, trusted context, constraints, tools, output schema, and failure behavior. Turn three common successes and three likely failures into test cases. Run the cases after every meaningful prompt or workflow change, review the outputs with the people who use them, and update the prompt only when the expected behavior is clear. That cycle keeps system prompt examples useful as living AI workflow templates rather than one-time instructions.