Reusable prompt templates make common LLM tasks easier to build, test, and maintain. This library compares practical patterns for extracting fields, classifying text, transforming content, and generating controlled summaries, with copyable examples, variables, expected outputs, and notes on failure modes.
Overview
Good prompt engineering is less about finding a clever sentence and more about defining a reliable interface between your application and a language model. A production prompt should make the task, input boundaries, output format, and uncertainty handling clear enough for another developer to review and test.
The templates in this guide use a shared structure:
- Role and task: what the model is responsible for doing.
- Input contract: which values are supplied and how they are delimited.
- Decision rules: definitions, thresholds, or priorities that affect the result.
- Output contract: the fields, labels, or format your application expects.
- Failure behavior: what to return when information is missing, ambiguous, or outside scope.
These patterns are useful for LLM app development, internal automation, support workflows, document processing, and API integrations. They are starting points rather than universal solutions. Test each prompt against representative examples, edge cases, and deliberately difficult inputs before placing it in a production AI workflow.
How to compare options
Choose a prompt pattern by looking first at the shape of the task, not at the wording of the prompt. Extraction asks, “Which values are present?” Classification asks, “Which predefined label applies?” Transformation asks, “How should this content be changed?” Summarization asks, “What information should be retained while reducing length?”
Compare candidate prompts using these criteria:
- Determinacy: Can two reviewers apply the instructions and reach the same expected result?
- Schema fit: Does the output map directly to the fields your code needs?
- Evidence handling: Does the prompt distinguish supplied facts from guesses?
- Boundary behavior: Is there an explicit response for missing, conflicting, or unsupported input?
- Validation effort: Can you check the result with rules, types, enums, or a test set?
- Maintenance cost: Can definitions and examples be updated without rewriting the entire instruction?
A simple comparison table helps select the right pattern:
| Task | Best pattern | Primary control | Common failure |
|---|---|---|---|
| Extract fields | Schema-first extraction | Field definitions and null rules | Invented or partially copied values |
| Classify text | Label-and-rationale classification | Closed label definitions | Inconsistent labels or forced guesses |
| Transform content | Constraint-preserving transformation | Keep, change, and forbidden-change rules | Meaning drift or format violations |
| Summarize content | Evidence-led controlled summary | Audience, length, priority, and omissions | Missing decisions or unsupported conclusions |
Feature-by-feature breakdown
1. Text extraction prompt
Use extraction when unstructured text must become predictable fields. Define each field precisely and state what to do when its value cannot be found.
System:
You extract structured data from the provided document. Use only information explicitly present in the document. Do not infer, complete, or normalize a value unless the rules below allow it.
Fields:
- customer_name: the full name of the customer; return null if absent.
- order_id: the order identifier, preserving letters, digits, and hyphens.
- order_date: the stated date; return null if absent. Do not guess the date format.
- total_amount: the stated total and currency; return null if either is absent.
Rules:
- If multiple values conflict, return the conflicting values in a notes field.
- Preserve the source wording when a value is ambiguous.
- Return valid JSON with keys: customer_name, order_id, order_date, total_amount, notes.
Document:
<document>{{document_text}}</document>Input variables: {{document_text}} is the source text. In an application, the JSON keys should be validated after generation. A null value is safer than a plausible-looking invention, especially when the result triggers billing, routing, or record updates.
Failure mode: Extraction prompts often fail when field definitions are vague. “Find the date” could mean an invoice date, delivery date, or payment date. Name the intended field and include a short example only when the distinction matters.
2. Classification prompt
Classification works best when the label set is closed and each label has an observable definition. Avoid asking the model to choose among overlapping labels without explaining priority.
System:
Classify the support message into exactly one category. Use the definitions below, not general assumptions.
Categories:
- billing: charges, invoices, refunds, or payment methods.
- technical_issue: a product feature is not working as expected.
- account_access: login, password, authentication, or account lockout.
- feature_request: the user proposes a new capability or change.
- other: none of the categories apply.
Decision rules:
1. If the message concerns both access and a technical issue, choose account_access when the user cannot sign in.
2. Choose other when the available information is insufficient.
3. Do not create new labels.
Return JSON:
{"category":"...","confidence":"high|medium|low","evidence":"short quote or paraphrase from the message"}
Message:
<message>{{message}}</message>Input variables: {{message}} is the text to classify. The evidence field makes review easier, but it is not a substitute for testing. If confidence is used for routing, define what your application should do with low-confidence results rather than treating every output as equally reliable.
Failure mode: Models may select the closest label even when none applies. An explicit other category and a rule for insufficient information reduce forced classifications.
3. Transformation prompt
Transformation changes presentation while preserving selected facts. Separate what may change from what must remain unchanged.
System:
Rewrite the supplied incident update for a technical audience.
Preserve:
- all dates, identifiers, measurements, and stated causes;
- the order of confirmed events;
- uncertainty markers such as " suspected" or " not confirmed".
Change:
- remove repetition;
- use concise, direct sentences;
- organize the result under Summary, Impact, Actions, and Next steps.
Do not:
- add facts not present in the source;
- convert a hypothesis into a confirmed cause;
- change identifiers or numeric values.
Return only the four requested sections.
Source:
<source>{{source_text}}</source>Input variable: {{source_text}} is the content being rewritten. For regulated or operational material, compare the source and result programmatically where possible, especially for identifiers, numbers, and required phrases.
Failure mode: A transformation prompt can improve readability while quietly changing meaning. Explicit preservation rules and a post-generation comparison are more dependable than asking the model to “keep the meaning” alone.
4. Controlled summary prompt
Summarization should define the reader, purpose, priority, and acceptable uncertainty. A short summary is not automatically useful if it omits the decision or action that motivated the request.
System:
Summarize the meeting notes for an engineering manager who needs decisions and follow-up actions.
Include:
- decisions that were explicitly made;
- unresolved questions;
- action items with an owner or "unassigned";
- dates only when stated in the notes.
Exclude:
- greetings, repetition, and unsupported interpretations;
- recommendations that were not discussed.
Use this format:
Decision:
- ...
Open questions:
- ...
Actions:
- [Owner] — [action] — [date or not stated]
If a section has no supported content, write "None stated."
Notes:
<notes>{{meeting_notes}}</notes>Failure mode: Summaries tend to sound complete even when the source is incomplete. Requiring “None stated” and separating decisions from recommendations helps preserve the difference between evidence and interpretation.
For machine-readable results, pair the prompt with schema validation, type checks, and a retry or repair path. The prompt should describe the desired structure, but application code should remain responsible for deciding whether an output is safe to accept. See the guide to structured output with LLMs for a deeper implementation pattern.
Best fit by scenario
- Document intake: Start with extraction. Use null rules, source references, and field-level validation before writing to a database.
- Ticket routing: Use classification with a closed label set, an other category, and an explicit low-confidence path for human review.
- Content normalization: Use transformation when the facts must remain stable but tone, structure, or formatting needs to change.
- Meeting and incident follow-up: Use controlled summarization with separate sections for decisions, actions, and unresolved issues.
- RAG applications: Keep retrieved context clearly delimited and instruct the model to distinguish evidence from missing information. Prompt design should complement retrieval and evaluation rather than compensate for poor source selection. The reliable RAG application guide covers that broader workflow.
When a workflow combines tasks, keep the stages conceptually separate where possible. For example, extract fields first, validate them, then classify or summarize the validated result. One large prompt may appear convenient, but separate stages make errors easier to locate and outputs easier to test.
When to revisit
Prompt templates should be treated as maintained application assets, not permanent text. Revisit a template when the input format changes, a new label or field is introduced, downstream validation rejects results, or users report a recurring misunderstanding. Also review prompts when changing models, response formats, context assembly, retrieval sources, or safety controls.
A practical maintenance cycle is:
- Keep a versioned copy of the prompt and its variable definitions.
- Maintain a small evaluation set containing normal, ambiguous, missing, and adversarial examples.
- Record expected outputs or acceptance criteria for each example.
- Run the set after prompt, model, schema, or workflow changes.
- Review both correctness and operational behavior, including invalid JSON, empty fields, excessive length, and unsupported claims.
- Promote a revision only after comparing it with the previous version on the same cases.
Use a prompt testing framework to measure accuracy, consistency, and safety over time rather than relying on a few successful manual trials. When a failure is found, update the smallest relevant part: clarify a definition, add a boundary rule, improve the output schema, or add a test case. Avoid continually adding instructions without removing ambiguity.
To apply this library, choose one pattern, replace its variables with your application inputs, define the failure path, and test it against real but appropriately handled examples. Then connect the result to validation and monitoring. This turns prompt engineering from one-off experimentation into a repeatable part of AI development and workflow maintenance.
