Skip to main content

How To Use This Page

The templates below are starting points. Each one captures a pattern that has proven reliable across many tasks of the same shape. Copy the relevant template, fill in the placeholders in curly braces, and refine from there. None are meant to be perfect for your specific case; all are meant to be 80 percent of the way to a working prompt. The patterns are grouped by task shape, not by domain. A classification prompt looks the same whether you are classifying support tickets or legal clauses; the differences live in the labels and the input, not in the structure. Many of these patterns are the same skeletons that power the PANTA OS Apps library.

Classification

The job: take an input, assign it to one of a fixed set of categories.
You are a {role}. Classify the {input_type} below into exactly one of the
following categories.

Categories:
- {category_1}: {definition_1}
- {category_2}: {definition_2}
- {category_3}: {definition_3}

Rules:
- Pick the single best best category, even if more than one fits.
- If none of the categories fit, respond with "uncategorized".
- Do not invent new categories.

Examples:
{example_input_1}
Category: {example_category_1}

{example_input_2}
Category: {example_category_2}

{example_input_3}
Category: {example_category_3}

Now classify the following:

{input}
Category:
Variants worth knowing:
  • Multi label. Replace “exactly one” with “all that apply” and switch the output to a comma separated list.
  • Hierarchical. Two stage chain: first classify into a top level category, then into a subcategory within that top level.
  • With confidence. Add “Then on a new line, give your confidence on a 1 to 5 scale” for high stakes classification.

Extraction

The job: pull structured information out of unstructured text.
You are a {role}. Extract the following fields from the {input_type} below.

Fields:
- {field_1} ({type_1}): {description_1}
- {field_2} ({type_2}): {description_2}
- {field_3} ({type_3}): {description_3}

Rules:
- Use only information present in the input.
- If a field cannot be determined from the input, set it to null.
- Do not infer values that are not stated.

Output format:
Return a single JSON object matching the schema. No preamble, no explanation.

{input_type}:
<input>
{input}
</input>
Common refinements:
  • Quote the source. Add a _source field for each extracted value containing the verbatim quote it was drawn from. Useful for audit and verification.
  • Multi entity. When the input contains multiple entities (e.g. multiple line items on an invoice), wrap the schema in an array and add a rule about how to identify entity boundaries.
  • Schema validation. Combine with the structured output features of the API for guaranteed valid JSON.

Summarization

The job: condense a longer text into a shorter one while preserving the important content.
You are a {role} producing summaries for {audience}.

Summarize the {input_type} below in {length}.

Requirements:
- Open with the {single_most_important_thing}.
- Cover {required_topic_1}, {required_topic_2}, and {required_topic_3}.
- Use plain English; define any acronym on first use.
- Do not editorialize. State what the source says, not what you think.

{input_type}:
<source>
{input}
</source>
Variants:
  • Executive summary. Three sections: headline (one sentence), key findings (one paragraph), implications (one paragraph). Total 250 to 300 words.
  • TL;DR. A single sentence at the start, followed by three to five bullets, followed by the next step.
  • Multi document. Wrap each input in <document> tags with metadata. Ask the model to identify common themes and contradictions across documents before summarizing.
For long source documents, ask the model to extract the relevant quotes first, then summarize from the quotes. The summaries are more grounded and easier to verify.

Drafting

The job: produce a first draft of original content based on a brief.
You are a {role} writing for {publication_or_context}.

Brief:
{brief}

Constraints:
- Length: {word_count}.
- Voice: {voice_descriptor}.
- Reading level: {reading_level}.
- Audience: {audience_descriptor}.
- Required elements: {required_elements}.
- Avoid: {forbidden_elements}.

Reference materials (use these as facts, not as style models):
<references>
{references}
</references>

Produce the draft. Do not include a preamble or commentary; output the draft only.
Drafting prompts benefit more from style examples than from instructions. If you have two or three pieces of writing that exemplify the voice you want, include them in <style_example> tags. The model will pick up the voice more reliably than from any prose description.

Transformation

The job: convert content from one form to another while preserving meaning.
Convert the {source_format} below into {target_format}.

Rules:
- Preserve all factual content.
- Do not add information that is not in the source.
- Do not omit information that is in the source.
- {format_specific_rule_1}
- {format_specific_rule_2}

Source:
<source>
{input}
</source>

Output:
Common transformations:
  • Translation. Source language to target language, with rules about terminology, formality register, and how to handle untranslatable terms.
  • Format conversion. Markdown to HTML, prose to bullet list, transcript to meeting notes, regulations to plain English.
  • Voice change. Formal to informal, technical to accessible, internal memo to public announcement.
  • Compression and expansion. Long to short with the same information, or short to long with elaboration that is grounded in the source.

Question Answering With Sources

The job: answer a question using a provided document, without inventing information.
You are a {role}. Answer the question using only the information in the source
documents below. If the answer is not in the documents, respond with "Not found
in the provided sources" and stop.

Process:
1. Extract every passage relevant to the question. Place each verbatim, with its
   document index, inside <quote> tags within a <quotes> wrapper.
2. Compose the answer based only on the extracted quotes. Place it inside
   <answer> tags.
3. Do not include information from outside the documents.

Question:
{question}

<documents>
<document index="1">
{document_1}
</document>
<document index="2">
{document_2}
</document>
</documents>
This is the canonical retrieval augmented generation pattern, and it is the same shape that powers question answering against the knowledge base of any PANTA OS Assistent. The “quote first” step makes the answer auditable: a reviewer can scan the quotes and confirm that the answer follows from them, without re reading the entire document.

Comparison

The job: compare two or more items along a defined set of dimensions.
Compare {item_a} and {item_b} along the following dimensions:

- {dimension_1}
- {dimension_2}
- {dimension_3}

For each dimension, describe the position of each item in one sentence, then state
which is stronger and why.

Output format:
A Markdown table with columns: dimension, {item_a}, {item_b}, stronger, reason.

Source material:
<item_a>
{item_a_input}
</item_a>
<item_b>
{item_b_input}
</item_b>
The structure prevents the most common failure of comparison prompts, which is the model declaring one item universally superior without dimension by dimension analysis.

Critique and Revision

The job: identify weaknesses in a piece of work and propose improvements.
You are a senior {role} reviewing the {artifact_type} below. Your job is to find
the weaknesses, not to praise the strengths.

For each weakness:
1. Quote the specific passage.
2. Name the type of issue (clarity, accuracy, structure, tone, evidence).
3. Explain why it is a problem in one sentence.
4. Propose a specific revision.

If the artifact is solid throughout, say so explicitly rather than inventing
weaknesses to find.

<artifact>
{input}
</artifact>
The “if it is solid, say so” line is doing important work. Without it, the model will sometimes invent weaknesses to satisfy the implicit demand of the prompt.

Routing and Decomposition

The job: take a complex request, decide what kind of task it is, and route it to the right specialist prompt.
You are a routing assistant. Read the user request below and decide which of the
following specialists should handle it.

Specialists:
- {specialist_1}: {description_1}
- {specialist_2}: {description_2}
- {specialist_3}: {description_3}

Output a single JSON object with the keys "specialist" (one of the names above)
and "reason" (one sentence). If the request is ambiguous, set specialist to
"clarification_needed" and reason to a one sentence question for the user.

User request:
{input}
Routing prompts are the entry point of agent systems. Keep them small and predictable. The downstream specialist prompts can be larger; the router should be fast and deterministic.

Closing Note

These templates are starting points, not finished products. Take the closest one, fill in the placeholders, run it on five to ten realistic inputs, and refine. The refinement is where the value is; the template just gets you to the point where refinement is the next step. For a deeper grounding in why these patterns work, return to Prompting Techniques and Structured Prompts.
Last modified on June 1, 2026