Example-Based Prompt Design

Introduction

Example-based prompt design is a prompting method in which one or more examples are included in a prompt to show an AI model how it should understand and complete a task.

Instead of explaining every rule in long instructions, examples demonstrate the expected pattern. They help the model understand the required input structure, output format, tone, classification logic, level of detail, and task boundaries.

Example-based prompt design is commonly used in:

• Few-shot prompting
• One-shot prompting
• Classification tasks
• Data extraction
• Text transformation
• Content generation
• Code generation
• Sentiment analysis
• Question answering
• Structured output generation

A well-selected example acts like a working demonstration. A weak, unclear, or biased example can guide the model in the wrong direction.

Purpose of Examples

Examples show the model what the user expects instead of depending only on written instructions.

They provide a practical demonstration of the task.

Main purposes of examples

Examples can help the model understand:

• What type of input it will receive
• What task it must perform
• What output structure it should follow
• Which information should be included
• Which information should be excluded
• What writing style should be used
• How detailed the answer should be
• How unusual cases should be handled
• How labels or categories should be assigned

Why examples improve prompts

Natural-language instructions can sometimes have multiple meanings. Examples reduce this uncertainty by showing the intended result.

Consider this instruction:

Classify the message as urgent or normal.

The meaning of urgent may not be clear. Adding examples makes the decision rule easier to understand.

Task: Classify each message as Urgent or Normal.
Example Input: The production server is unavailable.
Example Output: Urgent
Example Input: Please send the weekly report tomorrow.
Example Output: Normal
Actual Input: Customers cannot complete payments.
Actual Output:

The examples show that system failures and customer-blocking issues should be classified as urgent.

Examples as behavioural guidance

Examples guide model behaviour in the same way that demonstrations guide a human learner.

They can demonstrate:

• Correct task execution
• Correct formatting
• Correct level of detail
• Correct reasoning pattern
• Correct use of labels
• Correct handling of missing data
• Correct tone and vocabulary

Examples do not replace clear instructions

Examples are useful, but they should not completely replace instructions.

A strong example-based prompt normally contains:

1. A clear task
2. Relevant rules
3. One or more examples
4. The actual input
5. A clear output marker

Practical example

Task: Rewrite the sentence in a professional tone.
Keep the original meaning.
Do not add new information.
Example Input: Send me the file quickly.
Example Output: Please send me the file as soon as possible.
Actual Input: Tell me why this issue happened.
Actual Output:

Expected output:

Please explain why this issue occurred.

The example communicates the required tone more effectively than simply saying professional tone.

Representative Examples

A representative example is an example that closely matches the type of input the model will normally receive.

It should represent the common pattern of the real task.

Characteristics of a representative example

A representative example should:

• Match the real task
• Use realistic input
• Show the expected output
• Cover a common situation
• Use the same format as the actual input
• Use the same rules as the final task
• Avoid unusual details unless the task commonly contains them

Why representative examples matter

If an example is too different from the actual input, the model may learn the wrong pattern.

For example, imagine that a prompt must classify customer support tickets.

A weak example would be:

Example Input: I like your company.
Example Output: Positive Feedback

This example may be correct, but it does not represent common support requests such as refunds, login failures, delivery problems, or payment errors.

A more representative example would be:

Example Input: I was charged twice for the same order.
Example Output: Billing Issue

Representative example for data extraction

Task: Extract the customer name, order number, and issue.
Return the result in JSON.
Example Input: Rahul Sharma reported that order ORD-5821 arrived damaged.
Example Output: {"customer_name":"Rahul Sharma","order_number":"ORD-5821","issue":"Damaged product"}
Actual Input: Priya Patil said that order ORD-7604 has not been delivered.
Actual Output:

The example is representative because it contains the same types of information expected in the actual input.

Avoid overly simple examples

An example should not be so simple that it fails to demonstrate important task rules.

Weak example:

Input: Good
Output: Positive

Improved example:

Input: The application is easy to use, but it crashes during payment.
Output: Mixed

The improved example demonstrates how to handle multiple opinions in the same input.

Matching task difficulty

The example should have a difficulty level similar to the actual task.

For basic tasks, a simple example may be enough.

For complex tasks, the example should demonstrate:

• Multiple fields
• Conditional logic
• Required exclusions
• Error handling
• Structured output
• Special cases

High-Quality Examples

A high-quality example is correct, clear, relevant, complete, and consistent with the task instructions.

The model may copy patterns from the example. Therefore, every example should demonstrate the exact behaviour expected in the final response.

Qualities of a high-quality example

A strong example should be:

• Correct
• Relevant
• Clear
• Complete
• Realistic
• Consistent
• Unambiguous
• Properly formatted
• Free from unnecessary details

Correctness

The example output must be factually and logically correct.

Incorrect examples are especially harmful because the model may follow them even when the written instruction is correct.

Weak example:

Task: Classify the number as Even or Odd.
Example Input: 14
Example Output: Odd

The example directly conflicts with the task.

Correct example:

Task: Classify the number as Even or Odd.
Example Input: 14
Example Output: Even

Relevance

The example should directly support the task.

If the task is email classification, an example about product description generation is irrelevant.

Completeness

The example output should contain every required field.

Weak example:

Task: Extract name, email, and company.
Example Input: Anil from NovaTech can be contacted at anil@example.com.
Example Output: Name: Anil

Improved example:

Task: Extract name, email, and company.
Example Input: Anil from NovaTech can be contacted at anil@example.com.
Example Output: Name: Anil
Email: anil@example.com
Company: NovaTech

Clear relationship between input and output

A user should be able to understand why the example output was produced.

Avoid examples where the decision depends on hidden assumptions.

Realistic content

Examples should resemble real-world data.

Unrealistic examples may produce unrealistic output patterns.

Weak example:

Input: Product X is thing.
Output: Category Y

Improved example:

Input: Wireless keyboard with Bluetooth connectivity and rechargeable battery.
Output: Computer Accessories

High-quality text generation example

Task: Write a short product description.
Mention the main feature and customer benefit.
Use a friendly and professional tone.
Limit the response to 40 words.
Example Input: Stainless-steel water bottle, 750 ml, leak-proof lid
Example Output: Stay hydrated throughout the day with this durable 750 ml stainless-steel water bottle. Its leak-proof lid helps prevent spills, making it suitable for work, travel, exercise, and everyday use.
Actual Input: Wireless mouse, silent clicks, rechargeable battery
Actual Output:

This example clearly demonstrates the required length, tone, structure, feature, and benefit.

Positive Examples

A positive example shows the correct way to complete a task.

It demonstrates the output that the model should produce.

Purpose of positive examples

Positive examples help the model understand:

• Correct responses
• Accepted formats
• Desired writing style
• Correct labels
• Required fields
• Expected level of detail
• Proper handling of input

Positive example for classification

Task: Classify the review as Positive, Negative, or Mixed.
Example Input: The camera quality is excellent and the battery lasts all day.
Example Output: Positive
Actual Input: The software is fast and easy to use.
Actual Output:

Expected output:

Positive

Positive example for extraction

Task: Extract the employee name and department.
Example Input: Sneha Kulkarni joined the Finance department.
Example Output: Name: Sneha Kulkarni
Department: Finance
Actual Input: Rohan Mehta works in the Security department.
Actual Output:

Positive example for summarisation

Task: Summarise the text in one sentence.
Preserve the main fact.
Example Input: The company reduced delivery time by opening three new distribution centres across western India.
Example Output: The company opened three distribution centres in western India to reduce delivery time.
Actual Input: The team introduced automated testing and reduced software defects by 35 percent.
Actual Output:

When to use positive examples

Use positive examples when:

• The output format is important
• The task has a clear correct result
• A specific tone is required
• The model must copy a pattern
• The task is unfamiliar
• Instructions alone may be unclear

Limitation of positive examples

Positive examples show what to do, but they may not explain what should be avoided.

For tasks with common mistakes, combine positive examples with negative examples.

Negative Examples

A negative example shows an incorrect, unacceptable, or unwanted response.

It helps the model understand what it should not produce.

Negative examples should always be clearly marked as incorrect.

Purpose of negative examples

Negative examples can demonstrate:

• Incorrect formatting
• Unwanted language
• Missing information
• Excessive detail
• Unsupported claims
• Wrong classifications
• Unsafe responses
• Prohibited content
• Common task mistakes

Positive and negative example together

Task: Write a professional customer support response.
Do not blame the customer.
Positive Example Input: My payment failed twice.
Positive Example Output: We are sorry that your payment could not be completed. Please confirm whether the amount was deducted so we can guide you through the next step.
Negative Example Input: My payment failed twice.
Negative Example Output: You probably entered the wrong card details.
Reason Negative Example Is Wrong: It blames the customer and makes an unsupported assumption.
Actual Input: My order was cancelled without an explanation.
Actual Output:

Negative example for output formatting

Task: Return only valid JSON.
Correct Output: {"status":"approved","score":82}
Incorrect Output: The request is approved with a score of 82.
Reason Incorrect Output Is Wrong: It does not follow the required JSON format.

Negative example for data extraction

Task: Extract only information directly stated in the text.
Input: Amit works as a developer at BrightSoft.
Correct Output: {"name":"Amit","role":"developer","company":"BrightSoft"}
Incorrect Output: {"name":"Amit","role":"senior developer","company":"BrightSoft"}
Reason Incorrect Output Is Wrong: The word senior does not appear in the input.

Best practices for negative examples

When using negative examples:

• Clearly label them as incorrect
• Explain why they are wrong
• Keep the error focused
• Avoid showing too many bad patterns
• Include the correct version when possible
• Do not allow the negative example to look like a valid answer

Risk of unclear negative examples

If the prompt includes a bad output without clearly marking it as wrong, the model may copy it.

Weak structure:

Example Output: Do not return this long explanation...

Improved structure:

Incorrect Output: A long explanation with unnecessary details
Reason: The required response must contain only the category label.

Boundary Examples

A boundary example shows an input that is close to the limit between two categories, rules, or outcomes.

Boundary examples are useful when the task contains thresholds or closely related classifications.

Common uses of boundary examples

Boundary examples are useful for:

• Numerical thresholds
• Age groups
• Risk levels
• Sentiment levels
• Pass or fail rules
• Length limits
• Date ranges
• Confidence levels
• Priority levels
• Content moderation categories

Numerical boundary example

Suppose the classification rules are:

• Score below 40: Fail
• Score from 40 to 59: Pass
• Score 60 or above: Distinction

Useful boundary examples include:

Example Input: 39
Example Output: Fail
Example Input: 40
Example Output: Pass
Example Input: 59
Example Output: Pass
Example Input: 60
Example Output: Distinction

These examples clarify whether the limits are inclusive.

Boundary example for message priority

Task: Classify the support request as Low, Medium, or High priority.
Rule: High priority applies when users cannot access a paid service.
Boundary Example Input: The dashboard is slow, but I can still use it.
Boundary Example Output: Medium
Boundary Example Input: I cannot log in to my paid account.
Boundary Example Output: High
Actual Input: Reports take one minute to open, but all features are available.
Actual Output:

Boundary example for text length

Task: Classify the response length.
Short: 1 to 50 words
Medium: 51 to 150 words
Long: More than 150 words
Boundary Example Input: A response containing exactly 50 words
Boundary Example Output: Short
Boundary Example Input: A response containing exactly 51 words
Boundary Example Output: Medium

Why boundary examples are important

Without boundary examples, the model may make different decisions for values near a limit.

Boundary examples clearly show:

• Where one category ends
• Where another category begins
• Whether limits are inclusive
• How strict the rule should be

Counterexamples

A counterexample is an example that challenges an overly broad rule or common assumption.

It shows that a pattern does not apply in every situation.

Purpose of counterexamples

Counterexamples help prevent the model from:

• Applying a rule too widely
• Using simple keyword matching
• Making unsupported assumptions
• Ignoring context
• Confusing related categories
• Treating exceptions as normal cases

Counterexample for sentiment analysis

A weak sentiment system may classify every sentence containing the word excellent as positive.

Counterexample:

Input: The camera quality is excellent, but the phone overheats and becomes unusable.
Correct Output: Mixed
Explanation: The input contains both a positive feature and a serious negative issue.

This example prevents the model from depending only on the positive keyword excellent.

Counterexample for urgency classification

A weak rule may assume that every message containing immediately is urgent.

Input: Please send the updated logo immediately when you return next week.
Correct Output: Normal
Explanation: The request includes the word immediately, but the real deadline is next week.

Counterexample for spam detection

A weak system may classify every message containing free as spam.

Input: Your free trial will end tomorrow. Update your billing details to continue using your account.
Correct Output: Account Notification
Explanation: This is a valid service notification, not automatically spam.

Counterexample versus negative example

A negative example shows an incorrect output.

A counterexample shows that a general rule, keyword, or assumption does not always work.

Example:

• Negative example: Demonstrates a wrong answer
• Counterexample: Demonstrates an exception to a common pattern

When to include counterexamples

Use counterexamples when:

• The task has common false assumptions
• Keywords can be misleading
• Context changes the correct answer
• Categories overlap
• Exceptions are important
• The model may overgeneralise from examples

Input-Output Pairs

An input-output pair contains a sample input and the correct response for that input.

It is the basic structure used in one-shot and few-shot prompting.

Basic structure

Example Input: [sample input]
Example Output: [expected response]
Actual Input: [new input]
Actual Output:

Why input-output pairs work

Input-output pairs show the relationship between:

• Source data and result
• Question and answer
• Text and category
• Request and response
• Code requirement and generated code
• Unstructured text and structured output

Classification input-output pair

Task: Classify the ticket.
Allowed Categories: Billing, Technical, Account
Example Input: I was charged twice for my subscription.
Example Output: Billing
Example Input: The application closes whenever I open reports.
Example Output: Technical
Example Input: I forgot my password and cannot sign in.
Example Output: Account
Actual Input: The payment page shows an error after I enter my card details.
Actual Output:

Data extraction input-output pair

Task: Extract the product, quantity, and delivery city.
Return valid JSON.
Example Input: Send 25 wireless keyboards to Pune.
Example Output: {"product":"wireless keyboards","quantity":25,"delivery_city":"Pune"}
Actual Input: Deliver 10 office chairs to Mumbai.
Actual Output:

Text transformation input-output pair

Task: Convert the sentence from active voice to passive voice.
Example Input: The development team fixed the security issue.
Example Output: The security issue was fixed by the development team.
Actual Input: The manager approved the project plan.
Actual Output:

Code generation input-output pair

Task: Generate a Java method based on the requirement.
Use clear variable names.
Do not include a complete class.
Example Input: Create a method that returns the larger of two integers.
Example Output:
    public int findLargerNumber(int firstNumber, int secondNumber) {
        return Math.max(firstNumber, secondNumber);
    }
Actual Input: Create a method that checks whether a number is even.
Actual Output:

Important rules for input-output pairs

Each pair should:

• Use the same labels
• Use the same formatting
• Follow the same task rules
• Demonstrate the correct result
• Avoid unrelated explanation
• Match the expected final output

Consistent Example Formatting

Consistent formatting means that every example follows the same structure, labels, spacing, field order, and output style.

Consistency helps the model recognise the pattern correctly.

Why consistent formatting matters

Inconsistent examples can make the model uncertain about:

• Which fields are required
• Which labels should be used
• What output format is expected
• Whether explanations are required
• Whether the response should be short or detailed
• How multiple values should be arranged

Inconsistent example formatting

Input 1: The application is slow.
Result: Technical Issue
Example: I was charged twice.
Output Category: Billing
Customer Message: I forgot my password.
Answer: Account

Although the examples may be correct, the changing labels make the pattern less clear.

Consistent example formatting

Example Input: The application is slow.
Example Output: Technical Issue
Example Input: I was charged twice.
Example Output: Billing
Example Input: I forgot my password.
Example Output: Account
Actual Input: The payment page is not loading.
Actual Output:

Elements that should remain consistent

Keep the following elements consistent:

• Input label
• Output label
• Field order
• Capitalisation
• Punctuation
• JSON structure
• Date format
• Number format
• Category names
• Explanation style
• Response length

Consistent JSON examples

Weak formatting:

Example Output: {"name":"Amit", "age":30}
Example Output: Name: Sneha, Age: 28
Example Output: [Ravi, 25]

Improved formatting:

Example Output: {"name":"Amit","age":30}
Example Output: {"name":"Sneha","age":28}
Example Output: {"name":"Ravi","age":25}

Consistent example template

Task: [clear task]
Rules:
- [rule one]
- [rule two]
Example 1 Input: [input]
Example 1 Output: [output]
Example 2 Input: [input]
Example 2 Output: [output]
Actual Input: [new input]
Actual Output:

Example Ordering Strategies

Example ordering is the method used to arrange multiple examples inside a prompt.

The order of examples can affect how the model interprets the task.

Why ordering matters

Language models process prompt content in sequence. Examples that appear close to the actual input may have a stronger influence on the final response.

Poor ordering can:

• Hide the main pattern
• Overemphasise unusual cases
• Create category bias
• Make the prompt harder to understand
• Cause the model to copy the last example too closely

Simple-to-complex ordering

Start with a basic example and gradually introduce more difficult examples.

This strategy is useful when the task contains several rules.

Example 1: Simple single-category input
Example 2: Input containing multiple details
Example 3: Boundary or exception case
Actual Input: New task input

This helps the model learn the basic pattern before handling complexity.

Common-to-rare ordering

Place common examples first and unusual cases later.

This approach ensures that the main task behaviour is established before exceptions are introduced.

Recommended order:

1. Common case
2. Another common case
3. Boundary case
4. Rare exception
5. Actual input

Category-balanced ordering

For classification tasks, distribute examples across all important categories.

Weak ordering:

Positive
Positive
Positive
Positive
Negative

Improved ordering:

Positive
Negative
Mixed
Positive
Negative

Balanced ordering reduces the chance that the model will favour one category.

Alternating category ordering

Examples can be alternated to prevent long runs of the same label.

Billing
Technical
Account
Billing
Technical
Account

Place the most relevant example near the actual input

When one example closely matches the actual task, placing it near the actual input may improve pattern transfer.

However, do not place a misleading or overly specific example last.

Avoid placing only edge cases first

Starting with unusual cases may make the model treat them as normal.

Weak order:

1. Rare exception
2. Boundary case
3. Unusual input
4. Common input

Improved order:

1. Common input
2. Common input
3. Boundary case
4. Rare exception

Example ordering strategy for sentiment analysis

Task: Classify the review as Positive, Negative, or Mixed.
Example 1 Input: The laptop is fast and the battery lasts all day.
Example 1 Output: Positive
Example 2 Input: The screen stopped working after two days.
Example 2 Output: Negative
Example 3 Input: The display is sharp, but the keyboard feels uncomfortable.
Example 3 Output: Mixed
Actual Input: The camera is excellent, but the phone becomes very hot.
Actual Output:

The examples move from clear categories to a mixed case that is similar to the actual input.

Avoiding Example Bias

Example bias occurs when the examples influence the model to prefer a specific label, style, viewpoint, wording, group, or answer pattern without a valid reason.

Bias can enter a prompt through unbalanced, unrealistic, or one-sided examples.

Types of example bias

Common forms of example bias include:

• Label bias
• Position bias
• Topic bias
• Language bias
• Cultural bias
• Demographic bias
• Writing-style bias
• Length bias
• Positive or negative sentiment bias

Label bias

Label bias occurs when one category appears more often than others.

Weak example set:

• Five Positive examples
• One Negative example
• No Mixed example

The model may begin classifying uncertain inputs as Positive.

Improved set:

• Two Positive examples
• Two Negative examples
• Two Mixed examples

Position bias

Position bias occurs when the same category repeatedly appears first or last.

For example, if the final example always has the label High Priority, the model may overuse that label for the actual input.

Topic bias

Topic bias occurs when examples cover only one type of content.

Suppose a spam classifier uses only prize-related spam examples. It may fail to detect fake invoices, account warnings, or investment scams.

A better example set should include different realistic patterns.

Writing-style bias

If every example uses formal language, the model may fail to handle informal, incomplete, or misspelled user messages.

Balanced examples may include:

• Formal messages
• Informal messages
• Short messages
• Detailed messages
• Messages with spelling mistakes

Avoiding demographic bias

Do not associate names, locations, occupations, gender, age, or cultural background with negative outcomes unless those details are directly relevant to the task.

Weak approach:

Example Input: A person from a specific group applies for credit.
Example Output: High Risk

Improved approach:

Use task-relevant information such as payment history, verified income, debt level, or account activity.

Methods to reduce example bias

• Use balanced category counts
• Include different wording styles
• Include different realistic situations
• Remove irrelevant personal details
• Randomise example order during testing
• Test examples with varied inputs
• Include counterexamples
• Review hidden assumptions
• Avoid repeated keywords tied to one label

Bias review questions

Before using examples, ask:

• Does one label appear too often?
• Does one type of person always receive the same result?
• Are all examples written in the same style?
• Are unusual keywords controlling the output?
• Are personal details influencing unrelated decisions?
• Would the examples work for varied users and situations?

Avoiding Contradictory Examples

Contradictory examples are examples that teach different outputs for the same or very similar inputs without explaining the reason.

Contradictions reduce prompt reliability because the model cannot identify which pattern should be followed.

Direct contradiction

Example Input: The server is completely unavailable.
Example Output: High Priority
Example Input: The server is completely unavailable.
Example Output: Medium Priority

Both examples use the same input but produce different outputs.

Hidden contradiction

Rule: Any issue blocking payment must be High Priority.
Example Input: Customers cannot complete payments.
Example Output: Medium Priority

The example conflicts with the written rule.

Format contradiction

Rule: Return only JSON.
Example Output: The issue is classified as technical.

The output format conflicts with the instruction.

Tone contradiction

Rule: Use a polite and professional tone.
Example Output: You made a mistake. Fix your details and try again.

The example demonstrates an unfriendly tone.

How to prevent contradictory examples

• Check every example against the instructions
• Use one fixed category definition
• Keep label names consistent
• Review similar examples together
• Remove duplicate examples with different outputs
• Explain valid exceptions
• Test the prompt using near-identical inputs
• Maintain a source of truth for task rules

Valid differences should be explained

Sometimes similar inputs require different outputs because an important condition changes.

Example:

Example Input: One employee cannot access the dashboard.
Example Output: Medium Priority
Example Input: All employees cannot access the dashboard.
Example Output: High Priority
Explanation: The second issue affects the entire organisation.

These examples are not contradictory because the reason for the different outputs is clear.

Contradiction-checking process

1. List all task rules.
2. Review each example output.
3. Compare examples with similar inputs.
4. Check label definitions.
5. Check formatting requirements.
6. Identify unexplained differences.
7. Correct or remove conflicting examples.
8. Test the final example set.

Example Selection Checklist

The example selection checklist helps ensure that each example improves the prompt instead of adding confusion.

Task relevance

Check whether the example directly supports the current task.

• Does it demonstrate the required operation?
• Does it use realistic input?
• Does it match the actual use case?
• Does it include the expected type of data?

Correctness

Verify that the example output is accurate.

• Is the classification correct?
• Is the extracted data correct?
• Is the generated text suitable?
• Does the output follow all rules?
• Are there unsupported assumptions?

Clarity

Make sure the example is easy to understand.

• Is the input clear?
• Is the output clear?
• Is the relationship between them obvious?
• Are the labels meaningful?
• Is the example free from unnecessary information?

Format consistency

Check the structure of all examples.

• Are the same input labels used?
• Are the same output labels used?
• Is the field order consistent?
• Is capitalisation consistent?
• Is the output format valid?
• Are JSON keys written consistently?

Coverage

Confirm that the examples cover important cases.

• Is the common case included?
• Is each major category represented?
• Is a boundary case needed?
• Is an exception needed?
• Is a counterexample needed?
• Is missing information handled?

Balance

Review the distribution of examples.

• Does one category appear too often?
• Are positive and negative cases balanced?
• Are different writing styles represented?
• Are examples diverse without becoming unrelated?
• Are demographic details used only when relevant?

Ordering

Review how examples are arranged.

• Does the sequence move from simple to complex?
• Are common cases shown before rare cases?
• Are category labels distributed fairly?
• Is the most relevant example close to the actual input?
• Does the final example create unwanted bias?

Size and efficiency

Check whether every example is necessary.

• Does each example teach a new rule?
• Are any examples duplicates?
• Can a long example be shortened?
• Is the prompt becoming too large?
• Does the value of each example justify its token use?

Final example selection checklist

Use this checklist before finalising the prompt:

• The example matches the task.
• The input is realistic.
• The output is correct.
• The example follows every instruction.
• The format matches other examples.
• The example teaches a useful pattern.
• The example does not add hidden assumptions.
• The example does not create category bias.
• The example does not contradict another example.
• The example is short enough to understand quickly.
• Important categories are represented.
• Boundary conditions are clear.
• Negative examples are clearly marked.
• Counterexamples challenge common mistakes.
• The actual input is clearly separated from examples.

Improving Weak Examples

Weak examples may be incomplete, unrealistic, unclear, biased, inconsistent, or too simple.

Improving them requires identifying what the example fails to teach.

Weak example with unclear labels

Weak version:

Text: The app does not work.
Answer: Bad

Problems:

• The task is not stated
• The meaning of Bad is unclear
• The category is not defined
• The output format is inconsistent

Improved version:

Task: Classify the support ticket.
Allowed Categories: Technical Issue, Billing Issue, Account Issue
Example Input: The application closes immediately after I open it.
Example Output: Technical Issue

Weak example with incomplete output

Weak version:

Task: Extract the customer details.
Example Input: Meera Joshi from BrightTech can be contacted at meera@example.com.
Example Output: Meera Joshi

Problem:

The output does not include all requested fields.

Improved version:

Task: Extract the name, company, and email address.
Return valid JSON.
Example Input: Meera Joshi from BrightTech can be contacted at meera@example.com.
Example Output: {"name":"Meera Joshi","company":"BrightTech","email":"meera@example.com"}

Weak example with unrealistic content

Weak version:

Example Input: Person buys thing.
Example Output: Shopping

Problem:

The example does not resemble real user input.

Improved version:

Example Input: I ordered a wireless headset yesterday, but I have not received the tracking number.
Example Output: Order Tracking

Weak example with hidden assumptions

Weak version:

Example Input: Rohan applied for the position.
Example Output: Rejected

Problem:

The input contains no information that supports rejection.

Improved version:

Example Input: Rohan applied for a Java developer role requiring five years of experience. His application shows one year of Java experience.
Example Output: Does Not Meet Experience Requirement

Weak example with excessive detail

Weak version:

Example Input: A very long customer message containing background details, unrelated information, personal history, multiple dates, several complaints, and information that does not affect the classification.
Example Output: Billing

Problem:

The example consumes too much prompt space and hides the important pattern.

Improved version:

Example Input: I was charged twice for the same monthly subscription.
Example Output: Billing

Weak example with inconsistent formatting

Weak version:

Input: The payment failed.
Result: Billing
Customer says: I cannot log in.
Category = Account

Improved version:

Example Input: The payment failed.
Example Output: Billing
Example Input: I cannot log in.
Example Output: Account

Weak negative example

Weak version:

Bad Output: This response is not right.

Problem:

It does not explain what is wrong.

Improved version:

Incorrect Output: Your payment failed because you entered incorrect card details.
Reason Incorrect Output Is Wrong: It blames the customer and assumes a cause that was not provided.

Weak boundary example

Weak version:

Score: 50
Result: Pass

Problem:

One example does not explain the full threshold.

Improved version:

Rule: Scores below 40 are Fail.
Rule: Scores from 40 to 59 are Pass.
Rule: Scores of 60 or higher are Distinction.
Boundary Example Input: 39
Boundary Example Output: Fail
Boundary Example Input: 40
Boundary Example Output: Pass
Boundary Example Input: 59
Boundary Example Output: Pass
Boundary Example Input: 60
Boundary Example Output: Distinction

Step-by-step method for improving examples

1. Identify the purpose of the example.
2. Check whether the input matches the real task.
3. Verify that the output is correct.
4. Remove unrelated information.
5. Add missing required fields.
6. Standardise labels and formatting.
7. Remove hidden assumptions.
8. Add a boundary case when limits matter.
9. Add a counterexample when keywords may mislead.
10. Compare the example with the actual input.
11. Test whether the model follows the intended pattern.
12. Replace examples that produce unstable results.

Complete Example-Based Prompt Design

The following prompt combines clear instructions, input-output pairs, positive examples, a negative example, a boundary example, and consistent formatting.

Role: You are a customer support ticket classifier.
Task: Classify each customer message into one category.
Allowed Categories: Billing, Technical, Account, General
Rule: Use Billing for charges, refunds, invoices, and payment deductions.
Rule: Use Technical for application errors, crashes, slow performance, and unavailable features.
Rule: Use Account for login, password, profile, and account access problems.
Rule: Use General when the message does not match the other categories.
Rule: Return only the category name.
Positive Example Input: I was charged twice for my monthly plan.
Positive Example Output: Billing
Positive Example Input: The application crashes when I open the reports page.
Positive Example Output: Technical
Positive Example Input: I forgot my password and cannot sign in.
Positive Example Output: Account
Boundary Example Input: Where can I find information about your annual plan?
Boundary Example Output: General
Negative Example Input: My payment was deducted, but the subscription is not active.
Incorrect Output: Technical
Reason Incorrect Output Is Wrong: The main issue is related to payment and subscription billing.
Correct Output: Billing
Actual Input: I changed my password, but the system still says my account is locked.
Actual Output:

Expected output:

Account

Why this prompt is effective

This prompt works well because:

• The model receives a clear role
• The task is directly defined
• Allowed categories are listed
• Each category has a clear rule
• Positive examples demonstrate normal cases
• A boundary example shows when to use General
• A negative example explains a common mistake
• The actual input is clearly separated
• The required output is limited to one category name

Example-Based Data Extraction Prompt

Role: You are a structured data extraction assistant.
Task: Extract the employee name, job title, company, and city.
Rule: Use only information directly stated in the input.
Rule: Use null when a required value is missing.
Rule: Return valid JSON only.
Example Input: Kavita Sharma works as a product manager at Nova Systems in Pune.
Example Output: {"employee_name":"Kavita Sharma","job_title":"product manager","company":"Nova Systems","city":"Pune"}
Example Input: Akash works as a Java developer at CodeStack.
Example Output: {"employee_name":"Akash","job_title":"Java developer","company":"CodeStack","city":null}
Actual Input: Neha Patil is a security analyst at SecureWave in Mumbai.
Actual Output:

Expected output:

{"employee_name":"Neha Patil","job_title":"security analyst","company":"SecureWave","city":"Mumbai"}

Important design features

• The required fields are clearly listed
• Missing-value behaviour is demonstrated
• The output format is consistent
• The example does not invent information
• The final input follows the same structure

Example-Based Text Generation Prompt

Role: You are a professional technical content writer.
Task: Write a short feature description.
Rule: Mention the feature first.
Rule: Explain the user benefit.
Rule: Use simple and professional language.
Rule: Limit the response to two sentences.
Positive Example Input: Automatic cloud backup
Positive Example Output: Automatic cloud backup securely saves your latest files without requiring manual action. It helps protect important work when a device is lost, damaged, or replaced.
Negative Example Input: Automatic cloud backup
Incorrect Output: Our amazing and revolutionary cloud system is the greatest backup solution ever created.
Reason Incorrect Output Is Wrong: It uses exaggerated and unsupported marketing claims.
Actual Input: Real-time team notifications
Actual Output:

Expected output:

Real-time team notifications alert users when important project activity occurs. They help team members respond quickly and stay informed without repeatedly checking the application.

Example-Based Code Generation Prompt

Role: You are an experienced Java developer.
Task: Generate a Java method that validates the given input.
Rule: Return only the method.
Rule: Use clear variable names.
Rule: Handle null input.
Rule: Do not use external libraries.
Example Input: Create a method that checks whether a string is empty.
Example Output:
    public boolean isEmpty(String input) {
        return input == null || input.isEmpty();
    }
Actual Input: Create a method that checks whether a string contains only digits.
Actual Output:

Expected output:

public boolean containsOnlyDigits(String input) {
    if (input == null || input.isEmpty()) {
        return false;
    }
    for (int index = 0; index < input.length(); index++) {
        if (!Character.isDigit(input.charAt(index))) {
            return false;
        }
    }
    return true;
}

Why the code example is useful

The example demonstrates:

• The expected programming language
• The required method-only output
• Clear method naming
• Null handling
• Simple implementation style
• No external library use

Example-Based Prompt Design Best Practices

Keep examples task-focused

Every example should teach something useful about the task.

Remove examples that:

• Repeat the same pattern
• Add unrelated information
• Demonstrate unnecessary features
• Use a different output format
• Do not match the actual input

Prefer quality over quantity

A small number of strong examples is usually better than many weak examples.

Each additional example increases prompt length and token use.

Include an example only when it adds:

• A new category
• A new rule
• A boundary case
• An exception
• A formatting pattern
• A common error correction

Use realistic examples

Examples should resemble the data the model will receive in actual use.

Consider variations such as:

• Short and long input
• Formal and informal language
• Correct and incorrect spelling
• Complete and missing information
• Common and rare cases

Separate examples from actual input

Clearly mark where examples end and the real task begins.

Recommended labels:

• Example Input
• Example Output
• Actual Input
• Actual Output

Test with unseen inputs

Do not test only with inputs that closely copy the examples.

Use unseen cases to check whether the model learned the task instead of memorising wording.

Review generated output

Evaluate whether the model:

• Uses the correct format
• Selects the correct category
• Avoids unsupported information
• Handles missing values correctly
• Follows boundary rules
• Avoids copying irrelevant example details

Common Mistakes in Example-Based Prompt Design

Using incorrect examples

An incorrect example can override a correct written instruction.

Always verify outputs before using them.

Using examples that are too similar

Nearly identical examples do not provide useful coverage.

Use examples that demonstrate different valid situations.

Including too many examples

Large example sets increase cost, processing time, and context usage.

Remove examples that do not teach a new pattern.

Using inconsistent labels

Do not switch between labels such as:

• Technical
• Tech Problem
• System Error
• Application Issue

Choose one label and use it consistently.

Mixing correct and incorrect examples without labels

Always mark incorrect examples clearly.

Ignoring boundary cases

Threshold-based tasks require examples near the decision limits.

Creating category imbalance

A classification prompt should represent important labels fairly.

Using unrealistic clean data only

Real user input may contain:

• Spelling mistakes
• Missing punctuation
• Informal language
• Incomplete sentences
• Multiple issues

Include realistic variation when necessary.

Allowing examples to contradict rules

Examples and written instructions must describe the same behaviour.

Copying sensitive information into examples

Use fictional or anonymised data when creating demonstrations.

Do not expose real:

• Passwords
• API keys
• Payment data
• Medical records
• Personal identifiers
• Confidential business information

Example-Based Prompt Template

Role: [define the model role]
Task: [state the exact task]
Context: [provide necessary background]
Allowed Outputs: [list categories, formats, or valid values]
Rule: [state the first important rule]
Rule: [state the second important rule]
Rule: [state the output restriction]
Positive Example 1 Input: [representative input]
Positive Example 1 Output: [correct output]
Positive Example 2 Input: [different representative input]
Positive Example 2 Output: [correct output]
Boundary Example Input: [input close to a decision limit]
Boundary Example Output: [correct boundary result]
Counterexample Input: [input that challenges a common assumption]
Counterexample Output: [correct output]
Counterexample Explanation: [explain why the simple assumption is wrong]
Negative Example Input: [input related to a common mistake]
Incorrect Output: [unwanted output]
Reason Incorrect Output Is Wrong: [clear explanation]
Correct Output: [expected output]
Actual Input: [new task input]
Actual Output:

Final Summary

Example-based prompt design teaches an AI model through demonstrations.

Its effectiveness depends on the quality of the selected examples.

Strong examples should be:

• Correct
• Representative
• Clear
• Realistic
• Consistent
• Balanced
• Relevant
• Properly ordered
• Free from contradictions
• Aligned with the task instructions

Positive examples demonstrate correct behaviour.

Negative examples demonstrate what should be avoided.

Boundary examples clarify decision limits.

Counterexamples prevent overly broad assumptions.

Input-output pairs show the direct relationship between source data and expected results.

Consistent formatting makes the pattern easier to follow, while balanced selection reduces unwanted bias.

The best example set is not necessarily the largest set. It is the smallest set that clearly demonstrates the normal cases, important variations, boundaries, exceptions, required format, and common mistakes.

Frequently Asked Questions