In April 2024, I unveiled a guide to creating the perfect prompt, which can be found here on Medium. It is now one of the most widely used prompt engineering cheat sheets.

Feel free to download the cheat sheet as a PDF.

In this article, I will provide a short intro to each chapter in the cheat sheet along with prompt snippets for each example.

Now that SOTA LLMs can answer increasingly complex questions, the main difficulty is to elicit these by crafting the perfect prompt. This article serves as a cheat sheet, a collection of principles to help you prompting. We will run through:

• the AUTOMAT and the CO-STAR framework
• output format definition
• few-shot learning
• chain of thought
• prompt templates
• RAG, retrieval augmented generation
• formatting and delimiters and
• the multi-prompt approach.

The AUTOMAT and the CO-STAR Framework

AUTOMAT is an acronym that stands for:

1. Act as a Particluar persona (Who is the bot impersonating?)
2. User Persona & Audience (Who is the bot talking to?)
3. Targeted Action (What do you want the bot to do?)
4. Output Definition (How should the bot’s response be structured?)
5. Mode / Tonality / Style (How should its response be communicated?)
6. Atypical Cases (Are there edge cases where the bot should react differently?)
7. Topic Whitelisting (What relevant topics can the bot talk about?)

Here is an example of how to bring it all together:

Example Prompt Snippets

(A) Act as a ... this define the bot persona, be specific!

Act as a sensitive elderly psychotherapist ...
Act as a patient support staff ...
Act as a professional journalist ...
Act as a pebble, a car in love with its driver ...
Act as a 4th grader maths tutor ...
Act as a csh-terminal on the mac ...

(U) User Persona: This define the audience, their background and expected level of knowledge:

Explain it like to someone with an MSc in software engineering ...
... like to a 5-year-old child
... to the owner of the Tesla model S ...

(T) Task: Describe the task using meaningful verbs:

... summarise ...
... list ...
... translate ...
... classify …
... explain ...
... extract ...
... format ...
... comment ...
... document the code ...

(O) Output: Describe the form of the output. This is explained in more detail in the next section:

... a list of steps ...
... a formula ...
... a table ...
... python code ...
... a JSON ...
... a floating-point number between 0.0 and 1.0 ...
... a recipe with a list of ingredients for 4 persons ...
... a list of two-letter ISO country codes ...
... an iambic pentameter ...

(M) Mode: Use adjectives to describe the mode, tone, style: how the model should answer:

... empathetic ...
... confident ...
... aggressive ...
... moaning ...
... sarcastic ...
... witty ...
... stuttering ...
... Hemingway style ...
... like in a legal text ...

(A) Atypical: Describe atypical edge cases. This is generally only needed for models that are integrated into applications:

... and list these movies in a table with the columns "title", "director", "release date". If "director" or "release date" is missing, put a "-" to the cell. If the title is not known, don't put the movie into the table.

... if the answer on the question is not in the provided context, tell the user, you can't answer the question on basis of your material ...

... if the category of the mail is neither "offer", "confirmation", "receipt", set the category as "NULL" and don't fill the content fields.

... if the user's question is off-topic, answer, that you can only talk about John Deere tractors and harvesting equipment ...

... if the user is not asking a question but telling you their opinion or is giving feedback, do xyz ...

(T) Topic Whitelisting: List the allowed conversation topics:

... answer only questions regarding the CRB2004, it's features and operations. You make comments on user feedback regarding the device and tell the user something about your capabilities.

---

The CO-STAR framework is very similar to AUTOMAT, but with a slightly different focus. It stands for:

1. Context: (Why should the bot do this?)
2. Objective: (What should it do?)
3. Style & Tone: (How should it communicate its answer?)
4. Audience: (Who is the bot talking to?)
5. Response: (How should its response be structured?)

Evidently, many of the elements correspond directly to those of the AUTOMAT framework:

---

The Output Format

After stating the task, define the output format, i.e. how the answer should be structured. As with humans, giving an example usually helps the model to understand better:

Finally, specify:

• the permitted values
• how to respond if values are missing

This makes the task as clear as possible for the model to carry out:

Example Prompt Snippets

Define the output format:

### Task
Find 10 books similar to this book_title: {book_input}

### Output format
Return a JSON with an array of 10 items, each containing an object (the book) with the fields book_title, author, publication_date

Alternatively, show the output format by giving an example:

### Task
Classify the emails according to ...

### Output format
{
"sender_type": "customer",
"mail_type": "complaint",
"urgency": "low"
}

Further structure can be added by specifying the allowed values:

### Task
Classify the email according to ...

### Output format
...

### Allowed values in output
key | permitted values
sender_type | "customer", "supplier", "media", "other"
mail_type | "order", "invoice", "complaint", "other"
urgency | a float value between 0 and 1, with 0 = no
urgency and 1 = highest urgency

Also, don’t forget to show how to deal with missing information:

### Task
Classify the email according to ...

### Output format
...

### Allowed values in output
...

### Handling of information, which could not be determined
If a required field in the output JSON can not be determined set the variable to null like "urgency": null

---

Few-Shot Learning

Few-shot learning provides the model with a task and two types of examples:

• Standard cases: an example of how to match a typical input to output
• Special cases: an example of how to handle a common edge case

One example per use case is usually sufficient for the model to understand. Avoid listing similar examples:

Example Prompt Snippets

Create a separate section for the few shot examples:

# Task
List the core properties of a chemical element in a JSON,
when given the symbol.

### Examples
Input: "Mg"
Output: {"name": "magnesium", "symbol": "Mg", "atomic_number": 12, "atomic_weight": 24.350, "group": 2, "period": 3}

Show one example for each type of common edge case:

# Task
List the core properties of a chemical element in a JSON, when given the symbol.

### Examples
# Example 1:
Input: "Mg"
Output: {"name": "magnesium", "symbol": ...}

# Example 2:
Input: "Gm"
Output: {"Name": "None"}

# Example 3:
Input: "CO2"
Output: ...

Limit yourself to one or two examples per use case:

### Examples
# Example 1
... main use case a ...
# Example 2
... main use case b ...
# Example 3
... important edge case a ...
# Example 4
... important edge case b ...

---

Chain of Thought

Forcing the model to think aloud, i.e. to talk you through its chain of thought, generally produces better results (See the Google Brain Team article for more information). Provide a Q&A example of a similar problem, before asking your actual question and let the model follow your example.

Example Prompt Snippets

Show the model how to reason with 1-shot or few shot examples:

Q: Roger has 5 tennis balls. He buys 2 more cans of tennis balls. Each can has 3 tennis balls. How many tennis balls does he have now?
A: Roger started with 5 balls. 2 cans of 3 tennis balls each is 6 tennis balls. 5+6 = 11. The answer is 11.
Q: The cafeteria has 23 Apples. If they used 20 to make lunch and bought 6 more, how many apples do they have?

Using a key phrase such as "think step-by-step" forces the model into the CoT process:

### Task
Do x on the data y
...
Let us think step-by-step

Describe the process using an example:

### Task
Calculate the change of the customer lifetime value out of these data points:
{data}
...
Let us think step-by-step
The average purchase value of each customer in one year is the annual sales (
$ 4,273,392,000) divided by the average number of actual customers ($ 2,498,000) = 
$ 1,710. Take the average purchase value of a customer and divide it by the average customer lifespan (4.2 years) ...

---

Here is part 2 of the Prompt Engineering Cheat Sheet. Contents include:

• prompt templates
• RAG, retrieval augmented generation
• formatting and delimiters and
• the multi-prompt approach.