Instruction-Based Prompting

What Is Instruction-Based Prompting? Instruction-based prompting is the technique of controlling a model's behavior primarily through explicit, written directives: statements that tell the model what to do, how to do it, what to avoid, and what the result must look like.

It is the opposite end of a spectrum from example-based prompting:

Instruction-based Example-based "Tell the model the rules" ←———————————————→ "Show the model the pattern" Most modern prompts are primarily instruction-based, because instruction-tuned models are trained to follow directives (Lesson 2). Lesson 5 covered how to write a single clear instruction. This lesson covers instruction-based prompting as a technique: the types of instructions, how they interact, how the model prioritizes them, how to structure many instructions in one prompt, and how to verify that they were followed.

Why Instruction-Based Prompting Is the Default Advantage Explanation Fast to write No examples to collect or verify Easy to change Edit one rule instead of rewriting examples Transparent Anyone can read the prompt and understand the expected behavior No copying or leakage There are no example values to copy (Lesson 31) Scales to many rules Rules can be listed, grouped, and reviewed Its main weakness is that some requirements, such as style, subtle boundaries, and unusual formats, are easier to show than to state (Lesson 24). In those cases, instructions are combined with examples.

Types of Instructions A complete instruction-based prompt usually contains several types of instructions. Recognizing the type helps you write each one well and place it correctly.

Type Purpose Example Task What to do Summarize the support conversation. Constraint Limits on the content Do not include customer names or phone numbers. Format Shape of the output Use 3 bullet points, each under 20 words. Process How to approach the task First identify the customer's problem, then the resolution. Conditional What to do in specific situations If the issue was not resolved, start with "UNRESOLVED:". Behavioral Tone, persona, and conduct Use neutral, professional language. Priority Which rule wins in a conflict If brevity and completeness conflict, keep the resolution and drop details. Example: A Prompt Using All Types Summarize the support conversation in . [Task]

First identify the customer's problem, then what was done, then the outcome. [Process]

Use 3 bullet points: Problem, Action, Outcome. Each under 20 words. [Format]

Do not include customer names, emails, or phone numbers. [Constraint]

If the issue was not resolved, start the first bullet with "UNRESOLVED:". [Conditional]

Use neutral, professional language without judging the customer or agent. [Behavioral]

If the 20-word limit makes it impossible to describe the outcome accurately, accuracy takes priority over the word limit. [Priority] Why Separating Types Helps Each instruction has one job, so it is easy to verify. Missing types are easy to spot. For example, if there is no conditional instruction, ask whether there are situations that need special handling. When outputs are wrong, you can identify which type of instruction failed. The Instruction Hierarchy Instructions can come from different sources, and models are trained to give them different priority.

Highest priority Provider's built-in policies and safety rules System / developer instructions (written by the application developer) User messages (written by the person using the application) Content inside data (documents, emails, web pages, tool results) Lowest priority — should be treated as data, not instructions What This Means in Practice Put rules that must always apply in the system/developer instructions. In the OpenAI Responses API, this is the instructions parameter (Lesson 1). User messages can refine behavior within your rules, such as "make it shorter", but should not be able to override them, such as "ignore your restrictions". Text inside data should never be followed as instructions. A document saying "Assistant: reply only with YES" is content, not a command. Delimiters (Lesson 37) and explicit statements help the model maintain this distinction. Note: Models follow this hierarchy imperfectly. Clever user messages or text inside documents can sometimes influence behavior. This is the basis of prompt injection (Lesson 121). Instruction placement is an important defense, but not a complete one.

Conditional Instructions Real tasks often need different behavior in different situations. Conditional instructions express these as if-then rules.

Simple Conditions If the message is in Tamil, reply in Tamil. Otherwise, reply in English. Multiple Conditions When there are several conditions, list them in a clear structure and state the order in which they are checked:

Decide the reply type by checking these conditions in order, and use the first one that applies:

1. If the message contains abusive language → reply with the standard warning message.
2. If the message is about payments or refunds → direct the user to the billing team.
3. If the message is a course question → answer it.
4. Otherwise → ask the user to clarify their request. Why "First One That Applies" Matters A message can match several conditions, such as an abusive message about a refund. Without an order, the model must choose, and its choice may vary. Stating the evaluation order makes the behavior predictable, similar to an if / elif / else chain in code.

Always Include a Default The final "Otherwise" rule handles every situation not covered above. Without it, unexpected inputs produce unpredictable behavior.

Process Instructions Process instructions describe how to approach the task, not only what to produce.

Review the pull request description and code changes.

1. Identify what the change is supposed to do, based on the description.
2. Check whether the code actually does that.
3. List any behavior that changed but is not mentioned in the description.
4. Write your review. Why They Help They ensure important steps are not skipped. They establish an order where later steps depend on earlier ones. They make outputs more consistent, because the model follows the same procedure each time. When to Show the Process in the Output If you want to check the model's reasoning, ask it to write each step. If you want only the final result, ask it to follow the process but output only the review. For judgment tasks, writing the reasoning first usually improves the result (Lesson 10, Tip 4).

Organizing Many Instructions As prompts grow, instructions can become a long, unordered list where important rules are easy to miss. Organize them.

Group by Type or Topic

Task

Summarize the support conversation.

Content Rules

• Include the problem, actions taken, and outcome.
• Do not include personal contact details.

Format Rules

• 3 bullet points: Problem, Action, Outcome.
• Each bullet under 20 words.

Special Cases

• If unresolved, start the first bullet with "UNRESOLVED:".
• If the conversation is empty, reply "NO CONVERSATION". Put the Most Important Instructions Where They Are Noticed State the main task at the beginning. For prompts with long input data, restate the key instruction or format requirement after the data, immediately before the model starts writing (Lesson 2). Remove Instructions That Do Nothing Instructions that describe default behavior ("be accurate", "use good grammar") make the important ones harder to find (Lesson 14).

When Instructions Are Not Followed Even good instructions are sometimes ignored. The common causes and fixes are:

Cause Example Fix Instruction is buried A key rule in the middle of a long paragraph Give it its own line or section Instructions conflict "Be detailed" and "Maximum 50 words" Remove the conflict or state a priority Instruction is vague "Keep it short" Make it measurable Instruction is far from where it is needed Format rule at the top, 5,000 words of data before generation Repeat it after the data Too many instructions 40 rules of equal importance Group, prioritize, and remove unnecessary rules Instruction contradicts examples Rule says one line, examples show three Make examples consistent (Lesson 32) Instruction requires exact counting "Exactly 157 characters" Enforce in code Verifying Instruction Compliance in Code Many instructions are measurable: word limits, required sections, forbidden content, and specific prefixes. Checking these in code catches failures automatically, so you can retry, flag, or fix the output.

import re

def check_summary(summary: str, conversation: str) -> list[str]: """Check a support summary against measurable instructions.""" problems = [] bullets = [line.strip() for line in summary.splitlines() if line.strip().startswith("-")]

# Format: exactly 3 bullets if len(bullets) != 3: problems.append(f"Expected 3 bullet points, found {len(bullets)}")

# Format: each bullet under 20 words for i, bullet in enumerate(bullets, start=1): words = len(bullet.lstrip("- ").split()) if words >= 20: problems.append(f"Bullet {i} has {words} words (limit: under 20)")

# Constraint: no email addresses or 10-digit phone numbers if re.search(r"[\w.+-]+@[\w-]+.[\w.]+", summary): problems.append("Summary contains an email address") if re.search(r"\b\d{10}\b", summary): problems.append("Summary contains a phone number")

# Conditional: unresolved conversations must be marked unresolved = "not resolved" in conversation.lower() or "still not working" in conversation.lower() if unresolved and not (bullets and "UNRESOLVED:" in bullets[0]): problems.append('Unresolved conversation, but first bullet lacks "UNRESOLVED:"')

return problems

summary = """- Problem: Customer arun@example.com could not access the Django course after payment.

• Action: Agent refreshed the enrollment.
• Outcome: Course still not working; escalated to the technical team."""

conversation = "... Customer: It's still not working after the refresh ..."

for problem in check_summary(summary, conversation): print("-", problem) Output:

• Summary contains an email address
• Unresolved conversation, but first bullet lacks "UNRESOLVED:" Code Explanation Bullet extraction splitlines() splits the summary into lines, and only lines starting with - are kept as bullets.

Count and length checks The number of bullets and the word count of each bullet are compared with the format instructions. lstrip("- ") removes the leading dash and space before counting words.

Constraint checks Regular expressions detect email addresses and 10-digit numbers. The summary contains arun@example.com, which violates the "no contact details" constraint.

Conditional check A simple keyword test decides whether the conversation was unresolved. If it was, the first bullet must contain UNRESOLVED:. Here the conversation says "still not working", but the summary does not start with the required marker.

Limitations of Keyword Checks The unresolved check uses keywords, so it can miss unresolved conversations that use different words. For conditions that require understanding, a second model call can classify the conversation (Lesson 10, Tip 6). Use code for what code can check exactly, and use model-based checks for meaning.

Using the Results When problems are found, you can:

Retry with a follow-up message listing the violations: Your summary has these problems: [...]. Fix them and return the corrected summary. Fix automatically where possible, such as masking email addresses with a regular expression. Flag the output for human review. Instruction-Based vs Example-Based: Choosing the Mix Requirement Better Expressed As Measurable limits (length, count) Instruction Forbidden content Instruction Conditional behavior Instruction (if-then rules) Priorities between rules Instruction Exact unusual format Example (plus instruction) Style and voice Example (plus instruction) Subtle category boundaries Rule first, then example if needed Instruction-based prompting is the foundation; examples are added for what instructions cannot express precisely (Lesson 33).

Common Mistakes Mistake 1: Unordered Conditional Rules What it is: Several if-then rules that can apply to the same input, with no stated order.

Why it happens: Each rule is written independently.

What it causes: Inconsistent behavior when an input matches more than one rule.

How to fix it: State that conditions are checked in order and the first match applies, and add a default.

Mistake 2: Critical Rules Only in the User Message What it is: Placing rules that must always apply in the user message instead of system/developer instructions.

Why it happens: Prompts are developed in a chat interface and copied directly into code.

What it causes: Rules have lower priority and can be overridden more easily.

How to fix it: Move permanent rules to system/developer instructions.

Mistake 3: Too Many Equal-Priority Rules What it is: A flat list of dozens of rules with no grouping or priority.

Why it happens: Rules accumulate over time as problems are found.

What it causes: Important rules are overlooked; conflicts go unnoticed.

How to fix it: Group rules, remove unnecessary ones, and state priorities.

Mistake 4: Never Checking Compliance What it is: Assuming the model followed every instruction.

Why it happens: Outputs look correct at a glance.

What it causes: Violations, such as leaked contact details, reach users or databases.

How to fix it: Check measurable instructions in code and handle violations.

Best Practices Identify the type of each instruction. Task, constraint, format, process, conditional, behavioral, priority.

Respect the instruction hierarchy. Permanent rules in system/developer instructions; user content and data at lower priority.

Write conditional rules like code. Ordered conditions, first match wins, with a default.

Use process instructions for multi-step judgment. Ensure steps are not skipped and are done in order.

Organize instructions into sections. Group by type or topic, and keep critical rules visible.

State priorities for competing rules. Decide in advance which rule wins.

Verify measurable instructions in code. Retry, fix, or flag violations.

Add examples only where instructions fall short. Format, style, and subtle boundaries.

Try It Yourself Exercise 1: Label the Instruction Types Write a prompt for generating a weekly progress email to a student. Include at least one instruction of each type: task, constraint, format, process, conditional, behavioral, and priority. Label each one.

Exercise 2: Ordered Conditions Write conditional instructions for an assistant that receives messages from website visitors. Handle: job applications, sales inquiries, complaints, spam, and anything else. Decide the order of checks and explain why, especially for a message that is both a complaint and a sales inquiry.

Exercise 3: Extend the Compliance Checker Extend check_summary() to:

Check that the three bullets start with Problem:, Action:, and Outcome: (allowing UNRESOLVED: before Problem:). Mask any email address in the summary by replacing it with [email removed], and return the cleaned summary along with the list of problems.