Production prompt design becomes easier to maintain when every prompt has a clear purpose, explicit inputs, a defined output contract, and a testable failure path. This reusable prompt template library gives developers practical starting points for extraction, classification, summarization, rewriting, routing, and tool calling, along with guidance for adapting, versioning, and evaluating each template.
Overview
A prompt used in a prototype can be informal. A prompt used inside an AI feature needs to be more deliberate. It should tell the model what task it is performing, which information it may use, what format to return, and what to do when the input is incomplete or outside scope.
The templates below are not intended to be copied unchanged into every application. They are production prompt design patterns: compact structures that help teams make assumptions visible and keep prompt changes reviewable. Replace the bracketed variables with values from your application, then test the result against representative inputs before using it in a live workflow.
For output-heavy applications, pair these prompts with schema validation in your application code. A prompt can request valid JSON, but the application should still parse the response, validate required fields, handle refusals or malformed output, and decide whether to retry, fall back, or ask for human review. See How to Add Structured Outputs to LLM Apps with JSON Schemas and Validation for a deeper treatment of that boundary.
Template structure
A durable developer prompt usually contains the following layers. Not every task needs every line, but each layer answers a useful implementation question.
- Role and task: State what the model is responsible for and describe the operation in one sentence.
- Context: Provide the relevant source text, records, conversation history, or retrieved passages. Label untrusted or user-provided content clearly.
- Rules: Define inclusion criteria, exclusions, prioritization, tone, length, and permitted assumptions.
- Output contract: Specify the fields, types, allowed values, ordering, and formatting requirements.
- Uncertainty behavior: Explain what to return when evidence is missing, contradictory, or outside the task scope.
- Examples: Add a small number of representative examples when the task contains subtle distinctions that prose rules do not explain well.
A practical base template looks like this:
Task: [one-sentence task definition]
Input:
[input variable or delimited source content]
Instructions:
- Use only the supplied input unless [approved source or rule].
- Follow these decision rules: [rules].
- If the input is insufficient, [fallback behavior].
- Do not include [excluded content].
Return:
[output format or schema]
Quality checks:
- [check one]
- [check two]Keep stable instructions separate from dynamic variables in your AI API integration. This makes logging, testing, and version comparison easier and reduces the chance that a user-provided value accidentally changes the task definition.
How to customize
Start with the decision, not the wording
Before editing a prompt, write down the decision the application must make. For example, an email classifier may need to choose one of four queues, while a summarizer may need to produce a short internal brief. A precise decision makes it easier to remove decorative instructions and identify the fields that matter.
Use constrained variables
Name variables by purpose, such as source_text, customer_language, or retrieved_context. Define whether a variable is optional, how it is delimited, and what should happen when it is empty. For user-controlled content, state that the content is data to analyze rather than instructions to follow.
Prefer explicit output contracts
For machine-consumed results, describe a schema rather than asking for a generally formatted answer. Define required fields, null behavior, enumerated labels, and whether additional fields are allowed. If a value cannot be determined, a deliberate null or an unknown label is usually easier to handle than a guessed value.
Design the failure path
Production prompts should account for empty inputs, conflicting evidence, unsupported requests, and content that does not match the expected category. A useful fallback might be needs_review, an empty result array, or a structured error reason. The right choice depends on the surrounding workflow, so document it in the prompt and implement it in application logic.
For retrieval-based features, distinguish between the retrieved context and the model's general knowledge. Tell the model how to respond when the supplied passages do not support an answer. The RAG Application Architecture guide covers how prompting fits alongside chunking, embeddings, retrieval, and evaluation.
Examples
Extraction prompt
Extract the requested fields from the supplied document.
Document:
[document_text]
Fields:
- invoice_id: string or null
- due_date: ISO date or null
- total_amount: number or null
- currency: three-letter code or null
Rules:
- Copy values only when the document supports them.
- Do not infer a missing value from surrounding context.
- If multiple totals appear, select the final amount due and explain the selection in "notes".
Return one JSON object with the fields above and a "notes" string.Classification prompt
Classify the support message into exactly one queue.
Message:
[message_text]
Allowed queues:
- billing
- technical_issue
- account_access
- other
Rules:
- Choose the primary reason for contact.
- Use "other" when no queue is supported by the message.
- Do not classify based on sentiment alone.
Return:
{"queue":"...","confidence":"high|medium|low","evidence":"short quote"}Summarization prompt
Create a concise handoff summary from the case notes.
Case notes:
[case_notes]
Include:
- the customer's request
- actions already taken
- unresolved questions
- the next recommended step
Rules:
- Do not invent actions, dates, or commitments.
- Use four labeled sections and no more than [word_limit] words.
- If a detail is absent, write "Not provided".Tool-calling prompt
Decide whether a tool is needed to complete the user's request.
Available tools:
[tool_definitions]
User request:
[user_request]
Rules:
- Use a tool only when its stated purpose matches the request.
- Ask a clarifying question when required arguments are missing.
- Never invent tool arguments or claim a tool result that was not returned.
- After a tool response, summarize the result and identify any remaining limitation.These examples illustrate a broader prompt engineering principle: the prompt should define the boundary between interpretation and execution. The model can select a label or propose tool arguments, while your application remains responsible for authorization, validation, side effects, and retries.
Testing and versioning the templates
Treat prompts as application code. Store the prompt text, model configuration, schema, and test expectations together under a version identifier. Record which version produced each evaluation result so a change can be traced to a specific release.
Create a small test set before optimizing wording. Include normal examples, short and long inputs, ambiguous cases, missing fields, adversarial instructions inside source text, and examples that should trigger the fallback path. Evaluate both correctness and operational behavior: schema validity, refusal or escalation handling, latency, token use, and whether the output is useful to the next system component.
Use automated checks for deterministic properties, such as valid JSON, allowed labels, required fields, and maximum length. Use human review for qualities that are harder to reduce to a rule, such as relevance, factual support, tone, and appropriate uncertainty. The LLM Evaluation Framework and prompt evaluation pipeline guide provide useful structures for combining these methods.
When prompts handle sensitive inputs, review what is logged and retained. Test fixtures should be representative without exposing unnecessary personal or confidential data. Use the LLM logging and privacy checklist when defining observability requirements.
When to update
Revisit a prompt when the task, input distribution, output schema, model configuration, or surrounding workflow changes. A prompt that worked for a prototype may need new examples and fallback rules once real users introduce different phrasing or incomplete data.
Schedule a review after repeated production failures, a change to tool definitions, a new retrieval source, or an update to validation logic. Also review prompts when evaluation results drift, when reviewers identify a new ambiguity, or when a downstream consumer changes its expectations.
Keep a short change record for every revision: what changed, why it changed, which tests were added, and whether the change affects output compatibility. Avoid changing instructions, schema, and model settings simultaneously unless necessary; isolating changes makes results easier to interpret.
To put this library into practice, choose one high-value task, document its current inputs and failure cases, adapt the base template, and create a focused test set. Add schema validation before connecting the prompt to side effects, compare the revised version with the existing one, and release it behind a versioned configuration. That workflow turns prompt engineering from ad hoc wording into a repeatable part of AI product development.
