Introduction
Instruction-based prompting is a prompt engineering technique in which a user tells an AI model exactly what task it should perform, how it should perform that task, and what kind of result it should return.
The instruction may ask the model to:
- Explain a concept.
- Summarise a document.
- Generate code.
- Extract specific data.
- Classify text.
- Rewrite content.
- Follow a specific format.
- Avoid certain information.
- Apply rules under specific conditions.
For example:
Explain inheritance in Java using simple language.
Include one real-world example.
Include one Java code example.
Limit the explanation to 300 words.
Each line gives the model a clear instruction. Together, these instructions define the complete task.
Instruction-based prompting is one of the most important prompting techniques because almost every effective prompt contains one or more instructions.
What Is Instruction-Based Prompting?
Instruction-based prompting means directing an AI model through clear commands, rules, conditions, and output requirements.
Instead of providing only a topic, the prompt explains what the model must do with that topic.
A weak prompt may look like this:
Java exception handling
This prompt gives only a topic. It does not explain what type of response is required.
A stronger instruction-based prompt looks like this:
Explain Java exception handling for a beginner.
Describe checked and unchecked exceptions.
Include one example for each type.
Use simple language.
Return the answer in Markdown format.
The second prompt is more useful because it defines:
- The primary task.
- The target audience.
- The required topics.
- The writing style.
- The expected output format.
Instruction-based prompting reduces guessing and helps the model produce a more relevant response.
How Instruction-Based Prompting Works
Large language models generate responses by predicting suitable tokens based on the prompt and conversation context.
When instructions are clear, the model can identify:
- The action it must perform.
- The information it must use.
- The rules it must follow.
- The conditions it must evaluate.
- The format it must produce.
- The behaviour it must avoid.
A basic instruction-based prompt usually follows this flow:
- Identify the required task.
- Understand the supplied context.
- Process the input data.
- Apply the instructions and constraints.
- Generate the requested output.
- Check whether the result follows the required format.
Example:
Act as a Java interviewer.
Ask five questions about multithreading.
Ask one question at a time.
Wait for the user's answer before asking the next question.
Provide feedback after every answer.
Give a final score out of 10.
The model must understand several instruction types:
- Role instruction: Act as a Java interviewer.
- Content instruction: Ask questions about multithreading.
- Quantity instruction: Ask five questions.
- Sequential instruction: Ask one question at a time.
- Behavioural instruction: Wait for the user's answer.
- Evaluation instruction: Provide feedback.
- Formatting instruction: Give a score out of 10.
Main Components of an Instruction-Based Prompt
A complete instruction-based prompt may contain the following components:
| Component | Purpose |
|---|---|
| Role | Defines the model's expected role |
| Task | Defines the primary action |
| Context | Provides background information |
| Input | Supplies the data to process |
| Instructions | Defines required actions |
| Constraints | Defines limits and restrictions |
| Conditions | Defines situation-based behaviour |
| Output format | Defines the response structure |
| Success criteria | Defines what a correct result should contain |
| Fallback instruction | Defines what to do when information is missing |
Example:
Role: Act as a technical documentation writer.
Task: Rewrite the supplied API description.
Audience: Beginner backend developers.
Instructions: Explain every endpoint in simple language.
Constraint: Do not add endpoints that are not present in the input.
Output format: Use a heading, description, request example, and response example for each endpoint.
Fallback: Write "Not provided" when a required detail is missing.
Each component removes uncertainty from the task.
Explicit Instructions
Explicit instructions directly state what the model must do.
They normally use clear action words such as:
- Explain.
- Generate.
- Compare.
- Extract.
- Classify.
- Rewrite.
- List.
- Calculate.
- Validate.
- Summarise.
- Translate.
- Review.
Example:
Extract the customer's name, email address, and order number from the text.
Return the result as JSON.
Use null when a value is missing.
These instructions are explicit because every required action is directly stated.
Characteristics of explicit instructions
- They clearly define the task.
- They reduce the need for interpretation.
- They make output easier to validate.
- They are useful for technical and business workflows.
- They reduce inconsistent responses.
- They can define both required and prohibited actions.
Weak instruction
Tell me about REST APIs.
Improved explicit instruction
Explain what a REST API is.
Describe resources, endpoints, HTTP methods, and status codes.
Include one example using a product API.
Write for a beginner developer.
Keep the answer under 800 words.
Why explicit instructions are useful
The model does not need to guess:
- What depth is required.
- Which topics should be included.
- Who will read the answer.
- What format should be used.
- How long the answer should be.
Best practices
- Start each instruction with a clear action verb.
- Keep one main instruction per line.
- Use measurable requirements where possible.
- Clearly state the expected output.
- Avoid broad commands such as “make it good.”
- Replace subjective requirements with specific criteria.
Instead of:
Write a good explanation.
Use:
Explain the concept using simple language.
Include one definition.
Include two practical examples.
Avoid advanced mathematical details.
Implicit Instructions
Implicit instructions are expectations that are suggested by the prompt but are not directly stated.
The model understands them from:
- The wording of the request.
- The selected role.
- The supplied examples.
- The conversation history.
- The target audience.
- The format of the input.
- Common communication patterns.
Example:
Write a resignation email to my manager.
The prompt does not explicitly say:
- Use a professional tone.
- Include a greeting.
- Include a closing.
- Avoid insulting language.
However, these expectations are normally understood from the phrase “resignation email.”
Another example:
Explain photosynthesis to a seven-year-old child.
The prompt implies that the model should:
- Use simple words.
- Avoid advanced chemistry.
- Use familiar examples.
- Keep sentences short.
- Explain difficult terms.
Advantages of implicit instructions
- They keep prompts short.
- They work well for common tasks.
- They allow natural conversation.
- They reduce unnecessary detail.
Limitations of implicit instructions
- Different models may interpret them differently.
- The model may misunderstand the intended style.
- Important requirements may be ignored.
- Results may vary between responses.
- They are difficult to validate automatically.
Implicit versus explicit instruction
Implicit:
Create a professional project update.
Explicit:
Create a project update for senior managers.
Include completed work, current risks, delayed tasks, and next steps.
Use a formal and direct tone.
Limit the response to 250 words.
Do not include low-level technical details.
The explicit version gives more predictable results.
When implicit instructions are acceptable
Implicit instructions are suitable when:
- The task is simple.
- The expected format is common.
- Small variations are acceptable.
- The conversation already provides enough context.
Explicit instructions are better when:
- Accuracy is important.
- The output will be used in production.
- A fixed format is required.
- Multiple rules must be followed.
- The response will be processed by software.
Positive Instructions
Positive instructions tell the model what it should do.
They focus on the required behaviour, content, structure, or result.
Examples:
Use simple language.
Include practical examples.
Explain every technical term.
Return valid JSON.
Add a summary at the end.
Use descriptive variable names.
Provide step-by-step instructions.
Positive instructions are usually easier for a model to follow because they describe the desired result.
Benefits of positive instructions
- They provide a clear direction.
- They describe the expected outcome.
- They reduce uncertainty.
- They are easier to test.
- They encourage useful content.
- They are less likely to create confusion.
Example for content generation
Write a product description for a wireless keyboard.
Mention battery life, connectivity, key design, and compatibility.
Use clear and persuasive language.
End with a short call to action.
Example for code generation
Create a Python function that validates an email address.
Use a regular expression.
Return true for a valid email address.
Return false for an invalid email address.
Add type hints.
Include three test examples.
Positive instruction design
A positive instruction should answer one or more of these questions:
- What should the model include?
- What action should it perform?
- What structure should it follow?
- What quality should the result have?
- What should happen when the task is complete?
Weak positive instruction
Make the answer useful.
Improved positive instruction
Include a clear definition.
Explain how the concept works.
Include one technical example.
Include one real-world use case.
End with a short checklist.
Negative Instructions
Negative instructions tell the model what it must not do.
They are used to prevent:
- Unwanted content.
- Unsupported assumptions.
- Sensitive information.
- Repetition.
- Incorrect formats.
- Extra explanations.
- Irrelevant details.
- Unsafe actions.
Examples:
Do not invent missing information.
Do not include personal data.
Do not use complex technical terms.
Do not return Markdown.
Do not modify the supplied code.
Do not include information outside the provided document.
Why negative instructions are useful
Negative instructions define boundaries. They are important when the model has many possible ways to complete a task.
Example:
Summarise the supplied legal document.
Include only information found in the document.
Do not provide legal advice.
Do not guess the meaning of missing sections.
Clearly mark unclear information.
This prompt prevents the model from extending beyond the supplied evidence.
Problem with excessive negative instructions
A prompt containing too many negative instructions can become difficult to follow.
Weak approach:
Do not be long.
Do not be repetitive.
Do not be confusing.
Do not be technical.
Do not use large paragraphs.
Do not include unnecessary information.
Improved approach:
Keep the answer under 300 words.
Use simple language.
Use paragraphs of no more than four sentences.
Include only information required to answer the question.
The improved version changes vague negative rules into clear positive requirements.
Best practice
Use positive instructions to define the desired output and negative instructions to block specific risks.
Balanced example:
Explain dependency injection in Spring Boot.
Use simple language.
Include one constructor-injection example.
Limit the answer to 500 words.
Do not use field injection in the code example.
Do not discuss advanced container internals.
Priority Instructions
Priority instructions tell the model which requirement is more important when multiple instructions compete.
They are useful when a prompt contains:
- A primary task.
- Secondary tasks.
- Optional tasks.
- Safety requirements.
- Accuracy requirements.
- Length limits.
- Style preferences.
Example:
Priority 1: Preserve the technical meaning of the source text.
Priority 2: Simplify the language.
Priority 3: Shorten the content where possible.
Do not remove important technical details to satisfy the length preference.
The model now understands that correctness is more important than extreme shortening.
Why priority instructions matter
Without priority information, the model may not know how to handle competing requirements.
Example conflict:
Explain every important detail.
Keep the answer under 50 words.
These requirements may be impossible to satisfy together.
A priority instruction can resolve this:
Accuracy is more important than the 50-word target.
Keep the response close to 50 words, but exceed the limit when necessary to preserve essential information.
Ways to define priority
You can use:
- Priority numbers.
- Must, should, and may labels.
- Primary and secondary labels.
- Required and optional labels.
- Explicit conflict rules.
Example using requirement levels:
Must: Return valid JSON.
Must: Include productId, name, price, and stockStatus.
Should: Include a short product summary.
May: Include suggested tags when enough information is available.
Recommended priority model
- Safety and legal restrictions.
- Factual accuracy.
- Primary task completion.
- Required output format.
- Required constraints.
- Tone and style preferences.
- Optional improvements.
Priority instruction example
The primary goal is to identify security vulnerabilities.
Do not focus on code style until security analysis is complete.
Report critical vulnerabilities before medium and low-risk issues.
If the response becomes too long, remove optional style suggestions first.
Conditional Instructions
Conditional instructions tell the model to perform an action only when a specific condition is true.
They commonly use words such as:
- If.
- When.
- Unless.
- Otherwise.
- Only when.
- In case.
- Depending on.
Example:
If the input contains an email address, extract it.
If no email address is present, return "Email not found."
Conditional instructions support decision-based prompting.
Basic structure
If condition A is true, perform action A.
Otherwise, perform action B.
Example for customer support
If the customer asks about a delayed order, request the order number.
If the order number is already available, provide the current order status.
If the order cannot be found, advise the customer to contact support.
Do not request the order number more than once.
Example for data validation
If age is below 18, set eligibility to false.
If age is 18 or above, set eligibility to true.
If age is missing, set eligibility to unknown.
Example for code review
If the code contains a security issue, report it first.
If the code has no security issue, review performance problems.
If no performance problem is found, review readability.
If no issue is found, state that the code passed the review.
Designing reliable conditional instructions
- Define the condition clearly.
- Define the action for the true condition.
- Define the fallback action.
- Avoid overlapping conditions.
- Define the order when several conditions may be true.
- Explain whether the model should stop after one match.
- Cover missing or invalid input.
Weak condition
If necessary, explain more.
The phrase “if necessary” is unclear.
Improved condition
If the reader needs knowledge not explained earlier in the response, define that concept before continuing.
Multiple conditions
If the score is 80 or higher, classify the result as Excellent.
If the score is between 60 and 79, classify the result as Good.
If the score is between 40 and 59, classify the result as Needs Improvement.
If the score is below 40, classify the result as Poor.
If the score is missing or invalid, classify the result as Unknown.
Each condition has a clear and non-overlapping range.
Sequential Instructions
Sequential instructions define the order in which tasks must be completed.
They are important when:
- One step depends on another.
- The model must follow a workflow.
- The output must appear in a fixed order.
- Intermediate validation is required.
- The user wants a step-by-step process.
Example:
First, identify the main topic.
Second, list the key points.
Third, explain each key point.
Fourth, provide one practical example.
Finally, write a short summary.
Why sequence matters
Consider this prompt:
Rewrite the article.
Identify factual errors.
Correct the errors.
The order is unclear. The model may rewrite the article before identifying errors.
Improved version:
First, identify factual errors in the article.
Second, list the required corrections.
Third, rewrite the article using the corrected information.
Finally, verify that no identified error remains.
Sequential prompt for code generation
Step 1: Analyse the requirements.
Step 2: Identify the required classes and methods.
Step 3: Generate the Java implementation.
Step 4: Add input validation.
Step 5: Add unit tests.
Step 6: Explain how to run the tests.
Sequential prompt for content review
First, check grammar and spelling.
Next, check sentence clarity.
Then, remove repeated information.
Finally, provide the corrected version without showing the editing process.
Best practices
- Use numbered steps for long workflows.
- Put dependent actions in the correct order.
- State whether all steps are required.
- Define what each step should produce.
- Include a final validation step.
- Avoid mixing unrelated tasks in one step.
- State whether the model should stop and wait between steps.
Interactive sequence
Ask the user for the project name.
Wait for the user's response.
Ask for the project goal.
Wait for the user's response.
Ask for the target completion date.
Generate the project plan only after all three answers are available.
This workflow is different from asking all questions at once.
Behavioural Instructions
Behavioural instructions define how the model should behave while completing a task or interacting with a user.
They may control:
- Tone.
- Politeness.
- Questioning behaviour.
- Response style.
- Level of confidence.
- Handling of uncertainty.
- Interaction flow.
- Error handling.
- Use of assumptions.
- Feedback style.
Examples:
Be respectful and professional.
Ask one question at a time.
Clearly state when information is uncertain.
Do not pretend to know missing information.
Correct the user politely when a factual mistake is found.
Focus on practical guidance.
Behavioural instruction for tutoring
Act as a patient programming tutor.
Explain one concept at a time.
Ask a short question after each explanation.
Give a hint before providing the complete answer.
Encourage the learner without giving false praise.
Adapt the difficulty based on the learner's answers.
Behavioural instruction for technical support
Remain calm and direct.
Do not blame the user.
Ask only questions required for diagnosis.
Explain the reason for each troubleshooting step.
Warn the user before any step that may remove data.
Stop when the issue is resolved.
Behavioural instruction for uncertainty
Distinguish confirmed facts from assumptions.
State "I do not have enough information" when the evidence is incomplete.
Ask for missing information that is required for a reliable answer.
Do not create unsupported facts.
Behavioural versus content instructions
Behavioural instruction:
Use a patient and supportive tone.
Content instruction:
Explain how Java garbage collection works.
Behavioural instructions control how the answer is delivered. Content instructions control what information the answer contains.
Avoid vague behavioural instructions
Vague:
Be smart.
Be helpful.
Sound human.
Clear:
Use natural sentences.
Explain technical terms when first used.
Give direct answers before adding detail.
Avoid repeated warnings and generic introductions.
Content Instructions
Content instructions define what information must be included, excluded, explained, compared, or generated.
They are the central part of many prompts.
Examples:
Define polymorphism.
Explain compile-time polymorphism.
Explain runtime polymorphism.
Include one Java example for each type.
Compare both types in a table.
Add three interview questions.
Types of content instructions
- Required topics.
- Required facts.
- Required examples.
- Required sections.
- Required comparisons.
- Required source material.
- Required calculations.
- Required explanations.
- Excluded topics.
- Depth requirements.
Example for a technical article
Explain the Java Stream API.
Cover stream creation, intermediate operations, terminal operations, lazy evaluation, and parallel streams.
Include examples using filter, map, sorted, collect, and reduce.
Explain common performance mistakes.
End with a best-practices checklist.
Example for data extraction
Extract the invoice number.
Extract the invoice date.
Extract the customer name.
Extract the total amount.
Extract the payment status.
Do not extract product descriptions.
Example for comparison
Compare ArrayList and LinkedList.
Explain their internal data structures.
Compare access, insertion, deletion, and memory usage.
Include time-complexity information.
Recommend suitable use cases for each collection.
Content boundaries
A prompt should clearly state the scope.
Broad:
Explain Spring Boot.
Focused:
Explain dependency injection in Spring Boot.
Cover constructor injection and setter injection.
Do not discuss Spring MVC, Spring Security, or database integration.
A focused scope normally produces a deeper and more relevant response.
Content validation criteria
A strong content instruction can define completion conditions:
The answer is complete only when it includes:
A definition of dependency injection.
An explanation of inversion of control.
A constructor-injection code example.
A list of three benefits.
A list of two common mistakes.
Formatting Instructions
Formatting instructions define how the response must be organised and displayed.
They can control:
- Headings.
- Lists.
- Tables.
- JSON.
- XML.
- CSV.
- Paragraph length.
- Field names.
- Section order.
- Code formatting.
- Word count.
- Character count.
Example:
Return the response in Markdown format.
Start with a level-one title.
Use level-two headings for main sections.
Use bullet points for benefits.
Use a table for comparison.
End with a numbered checklist.
Formatting instruction for JSON
Return valid JSON only.
Use the fields name, email, phone, and status.
Use null for missing values.
Do not include comments.
Do not include text before or after the JSON object.
Expected structure:
{
"name": "Ravi Kumar",
"email": "ravi@example.com",
"phone": null,
"status": "active"
}
Formatting instruction for a table
Return the comparison as a Markdown table.
Use the columns Feature, ArrayList, and LinkedList.
Include rows for Data Structure, Access, Insertion, Deletion, and Memory.
Keep each cell under 25 words.
Formatting instruction for code
Generate Java 21 compatible code.
Use one public class named EmployeeService.
Use constructor injection.
Use meaningful variable names.
Add only single-line comments.
Do not include empty lines.
Use proper indentation.
Example output:
public class EmployeeService {
private final EmployeeRepository employeeRepository;
// Inject the repository through the constructor
public EmployeeService(EmployeeRepository employeeRepository) {
this.employeeRepository = employeeRepository;
}
public Employee findEmployee(Long employeeId) {
return employeeRepository.findById(employeeId);
}
}
Why formatting instructions fail
Formatting instructions may fail when:
- The format is not clearly defined.
- Required fields are missing.
- Two formats are requested at the same time.
- An example contradicts the written instruction.
- The requested format cannot represent the required information.
- Optional and required fields are not separated.
Improved formatting requirement
Instead of:
Give the answer in a proper format.
Use:
Return the answer in Markdown.
Use the sections Definition, How It Works, Example, Benefits, Limitations, and Summary.
Use bullet points for benefits and limitations.
Keep each paragraph under five sentences.
Instruction Placement
Instruction placement refers to where instructions are located inside a prompt.
The position of an instruction can affect how clearly the model understands it.
Instructions may be placed:
- At the beginning.
- Before the input data.
- After the input data.
- Inside labelled sections.
- Near the related content.
- At both the beginning and end for important requirements.
Instructions at the beginning
Placing the main task near the beginning helps the model understand the purpose before reading the input.
Example:
Task: Summarise the customer feedback.
Instructions: Identify the three most common problems.
Input: The customer feedback appears below.
This structure is clear because the model knows what to look for while processing the input.
Instructions after the input
Instructions may also appear after the data:
Customer feedback:
The application is slow during login.
The payment page sometimes fails.
The support team responds late.
Task:
Identify the reported problems.
Group similar problems.
Return the result as a table.
This can work, but long input may reduce the visibility of instructions placed only at the end.
Recommended placement
For long prompts, use this order:
- Role.
- Primary task.
- Context.
- Input data.
- Detailed instructions.
- Constraints.
- Output format.
- Validation rules.
Example:
Role: Act as a business analyst.
Task: Analyse the customer survey data.
Context: The survey was collected after a mobile application update.
Input: Use the survey comments provided below.
Instructions: Identify positive feedback, complaints, and feature requests.
Constraints: Do not invent customer opinions.
Output format: Return three tables.
Validation: Every comment must appear in exactly one category.
Place related instructions together
Avoid scattering related rules across the prompt.
Weak structure:
Write an article.
Use the data below.
Keep it short.
Here is the data.
Use Markdown.
Include examples.
Do not exceed 600 words.
Improved structure:
Task: Write an article using the supplied data.
Content: Include a definition and two examples.
Format: Use Markdown.
Length: Keep the article under 600 words.
Input: Use the data provided below.
Repeat only critical constraints
Unnecessary repetition can make the prompt longer and create contradictions.
However, a critical rule may be restated near the output requirement:
Use only the supplied document as the factual source.
Do not include facts from general knowledge.
Final check: Remove any claim that is not supported by the supplied document.
Instruction Conflicts
Instruction conflicts happen when two or more instructions cannot be followed together or lead to different actions.
Example:
Explain the topic in complete detail.
Keep the answer under 50 words.
A complete explanation may require more than 50 words.
Another conflict:
Return JSON only.
Explain the result in a paragraph after the JSON.
The model cannot return JSON only and also add a paragraph outside the JSON.
Common types of instruction conflicts
- Length conflict.
- Format conflict.
- Tone conflict.
- Scope conflict.
- Sequence conflict.
- Content conflict.
- Role conflict.
- Accuracy conflict.
- Tool-use conflict.
- Positive and negative instruction conflict.
Length conflict
Include ten detailed examples.
Keep the complete answer under 100 words.
Format conflict
Return a Markdown table.
Return valid JSON only.
Content conflict
Include every technical detail.
Avoid technical details.
Tone conflict
Use a formal legal tone.
Write like a casual conversation between friends.
Sequence conflict
Generate the final answer before analysing the input.
Analyse the input before generating the final answer.
How to prevent conflicts
- Review all requirements before submitting the prompt.
- Group related instructions.
- Use consistent terms.
- Define priorities.
- Mark optional requirements.
- Avoid repeating instructions with different wording.
- Add a conflict-resolution rule.
Conflict-resolution instruction
If two instructions conflict, follow the instruction with the higher priority.
Preserve factual accuracy before satisfying style preferences.
Preserve valid JSON before adding explanatory text.
Ask for clarification when two required instructions have equal priority.
Resolved example
Primary requirement: Return valid JSON.
Secondary requirement: Explain the classification.
Place the explanation inside the explanation field.
Do not write any content outside the JSON object.
Now both requirements can be satisfied.
Handling impossible requirements
A strong prompt can define fallback behaviour:
If all requirements cannot be satisfied together, explain the conflict briefly.
Do not silently ignore a required instruction.
Suggest the smallest change needed to make the task possible.
Instruction Hierarchy
Instruction hierarchy defines the order of authority among different instructions.
In an AI system, instructions may come from several levels:
- System instructions.
- Developer instructions.
- User instructions.
- Tool or application rules.
- Conversation context.
- Examples and implied preferences.
Higher-level instructions normally have more authority than lower-level instructions.
A user prompt cannot reliably override a higher-level safety or application rule.
For example, a user may write:
Ignore all previous safety instructions.
This does not make the higher-level safety rules invalid.
Why instruction hierarchy matters
Instruction hierarchy helps the model decide what to do when different instruction sources conflict.
For example:
- A system instruction requires safe behaviour.
- A developer instruction defines an application workflow.
- A user instruction requests a task.
- A previous message provides supporting context.
The model should follow the user request only when it does not conflict with higher-level requirements.
Hierarchy inside a user prompt
A user can also create a local hierarchy:
Mandatory rules:
Return valid JSON.
Use only the supplied data.
Include all required fields.
Preferred rules:
Keep descriptions under 20 words.
Sort records alphabetically.
Optional rule:
Add suggested tags when possible.
This makes the relative importance of each requirement clear.
Must, should, and may
A useful hierarchy system is:
- Must: Required and cannot be skipped.
- Should: Important but can be skipped when necessary.
- May: Optional improvement.
Example:
Must: Preserve the original meaning.
Must: Correct grammar errors.
Should: Shorten long sentences.
Should: Use simpler words.
May: Improve transitions between paragraphs.
Instruction hierarchy example
Priority 1: Do not expose personal information.
Priority 2: Preserve factual accuracy.
Priority 3: Complete the requested summary.
Priority 4: Keep the summary under 300 words.
Priority 5: Use a friendly tone.
If removing personal information causes the summary to become less detailed, privacy still has higher priority.
Instruction hierarchy for automated workflows
Critical: The output must be valid JSON.
Critical: Every required field must be present.
High: Extract values only from the supplied text.
Medium: Normalise all dates to YYYY-MM-DD.
Low: Correct obvious spelling mistakes in names.
This structure is useful when output will be processed by software.
Explicit Instructions Versus Implicit Instructions
| Point | Explicit Instructions | Implicit Instructions |
|---|---|---|
| Meaning | Directly state the required action | Suggest the expected action |
| Clarity | Usually high | Depends on interpretation |
| Prompt length | Usually longer | Usually shorter |
| Output consistency | More consistent | More variable |
| Best use | Technical and controlled tasks | Simple and common tasks |
| Validation | Easier | More difficult |
| Risk | Overly detailed prompt | Misunderstood expectation |
Example
Implicit:
Prepare this content for executives.
Explicit:
Rewrite the content for senior executives.
Start with the main business impact.
Include financial risk, delivery risk, and the required decision.
Remove low-level implementation details.
Keep the response under 400 words.
Positive Instructions Versus Negative Instructions
| Point | Positive Instructions | Negative Instructions |
|---|---|---|
| Purpose | Define what to do | Define what to avoid |
| Direction | Desired result | Restricted result |
| Example | Include two examples | Do not include theory |
| Main benefit | Guides generation | Prevents unwanted output |
| Risk | May leave boundaries unclear | Too many restrictions may confuse |
| Best approach | Use as the main instruction type | Use for important boundaries |
Balanced example:
Explain encapsulation using simple language.
Include one Java example.
Include one real-world example.
Do not discuss inheritance or polymorphism.
Do not use code that exposes fields publicly.
Priority Instructions Versus Sequential Instructions
Priority and sequence solve different problems.
Priority instructions answer:
- Which requirement is more important?
Sequential instructions answer:
- In which order should actions be performed?
Example combining both:
Priority 1: Identify security problems accurately.
Priority 2: Suggest fixes.
Priority 3: Suggest code-style improvements.
First, review authentication and authorisation.
Second, review input validation.
Third, review data storage.
Finally, review code readability.
Priority defines importance. Sequence defines workflow order.
Instruction-Based Prompting for Classification
Instruction-based prompting can classify text into predefined categories.
Example:
Classify the customer message into one category.
Allowed categories: Billing, Technical Issue, Delivery, Refund, General Question.
Return only the category name.
Do not create a new category.
Message: My payment was completed, but the order still shows unpaid.
Expected response:
Billing
Improved classification prompt
Task: Classify the customer message.
Categories:
Billing: Payment, invoice, charge, or pricing problems.
Technical Issue: Application, website, login, or software problems.
Delivery: Shipping, tracking, or delayed delivery problems.
Refund: Refund requests or refund-status questions.
General Question: Questions that do not match another category.
Rule: Select exactly one category.
Rule: Return only the category name.
Input: My parcel has not arrived, and the tracking page has not changed for five days.
Expected response:
Delivery
Instruction-Based Prompting for Data Extraction
Instruction-based prompting can convert unstructured text into structured data.
Example:
Extract the candidate name, primary skill, total experience, and location.
Return valid JSON.
Use null when a value is missing.
Do not guess missing values.
Input: Rahul Sharma is a Java developer based in Pune with six years of experience.
Expected response:
{
"candidateName": "Rahul Sharma",
"primarySkill": "Java",
"totalExperience": "6 years",
"location": "Pune"
}
Important extraction instructions
- Define all fields.
- Define accepted value types.
- Define missing-value behaviour.
- Define output format.
- Prevent guessing.
- Define whether values should be normalised.
- Define how multiple values should be handled.
Instruction-Based Prompting for Summarisation
A summarisation prompt should define:
- The source content.
- The target audience.
- The desired length.
- Important information to preserve.
- Information to exclude.
- The output structure.
Example:
Summarise the supplied project report for senior management.
Include current status, completed milestones, delays, risks, and next steps.
Remove low-level technical details.
Preserve all dates, amounts, and percentages.
Keep the summary under 350 words.
Use the headings Status, Progress, Risks, and Next Steps.
This is stronger than:
Summarise this report.
Instruction-Based Prompting for Content Generation
Content-generation prompts can control subject, audience, structure, tone, length, and coverage.
Example:
Write a beginner-friendly article about Java interfaces.
Start with a simple definition.
Explain why interfaces are used.
Compare interfaces with abstract classes.
Include one real-world example.
Include one Java code example.
Add a common-mistakes section.
End with five interview questions.
Use Markdown format.
Keep the article under 1,500 words.
The model receives clear content and formatting instructions.
Instruction-Based Prompting for Code Generation
Code generation requires precise technical instructions.
Example:
Create a Java 21 program that reads a list of employee salaries.
Calculate the total salary.
Calculate the average salary.
Find the highest salary.
Reject negative salary values.
Use BigDecimal for salary calculations.
Use meaningful method names.
Add only single-line comments.
Do not include empty lines.
Include a main method with sample data.
Explain the time complexity after the code.
A vague prompt such as “create salary code” may produce an unsuitable implementation.
Useful code-generation requirements
- Programming language and version.
- Framework and version.
- Input type.
- Output type.
- Required functions or classes.
- Error handling.
- Security requirements.
- Performance requirements.
- Dependency restrictions.
- Testing requirements.
- Formatting rules.
Instruction-Based Prompting for Code Review
Example:
Review the supplied Java code.
Identify correctness problems first.
Identify security issues second.
Identify performance issues third.
Identify readability problems last.
For every issue, include severity, affected line, explanation, and corrected code.
Do not rewrite code that does not need correction.
State "No issue found" when a category has no problem.
This prompt combines:
- Priority instructions.
- Sequential instructions.
- Content instructions.
- Formatting instructions.
- Negative instructions.
- Fallback instructions.
Common Instruction-Based Prompting Mistakes
Using unclear action words
Weak:
Handle this text.
Improved:
Correct grammar errors in the text.
Preserve the original meaning.
Return only the corrected text.
Combining many actions in one sentence
Weak:
Read this, fix it, explain it, make it short, add examples, and return JSON.
Improved:
Review the supplied text.
Correct factual and grammar errors.
Write a summary under 150 words.
Include one example.
Return the result using the supplied JSON structure.
Using subjective requirements
Weak:
Make the answer professional and impressive.
Improved:
Use a formal business tone.
Start with the main recommendation.
Support the recommendation with three reasons.
Avoid exaggerated claims.
Keep the response under 500 words.
Missing output format
Weak:
Extract all product information.
Improved:
Extract product name, brand, price, currency, and stock status.
Return a JSON array.
Use null for missing values.
Do not include information outside the JSON array.
Missing fallback instructions
Weak:
Find the invoice number.
Improved:
Extract the invoice number.
Return "Invoice number not found" when no invoice number is present.
Do not create an invoice number.
Contradictory instructions
Weak:
Use only one sentence.
Include a detailed introduction, five examples, and a conclusion.
Improved:
Write a detailed response with an introduction, five examples, and a conclusion.
Keep each paragraph under five sentences.
Too many restrictions
Weak:
Do not be long.
Do not be short.
Do not be formal.
Do not be casual.
Do not use simple words.
Do not use complex words.
Improved:
Use a neutral professional tone.
Use common technical vocabulary.
Explain specialised terms when first used.
Keep the response between 500 and 700 words.
Depending too much on implied meaning
Weak:
Make this suitable for my website.
Improved:
Rewrite the content for a beginner programming tutorial website.
Use clear headings and short paragraphs.
Include one practical example.
Avoid marketing claims.
Return copy-paste-ready Markdown.
Best Practices for Writing Instructions
- Define one clear primary task.
- Start instructions with direct action verbs.
- Put one instruction on each line.
- Separate required and optional instructions.
- Define priority when requirements may compete.
- Define conditions using clear if-and-otherwise rules.
- Define workflow order for dependent tasks.
- Describe desired behaviour using observable rules.
- Specify required content.
- Define the exact output format.
- Add fallback instructions for missing data.
- Avoid vague words such as good, proper, nice, and better.
- Replace subjective rules with measurable requirements.
- Keep related instructions together.
- Check the prompt for contradictions.
- Include examples when the format is difficult to describe.
- Define what the model must not invent.
- Add a final validation instruction for important tasks.
Instruction Quality Checklist
Before using an instruction-based prompt, check the following points:
- Is the primary task clearly stated?
- Does each instruction contain one clear action?
- Are all required topics listed?
- Is the target audience defined?
- Is the required output format defined?
- Are length limits measurable?
- Are conditions complete and non-overlapping?
- Is the order of dependent steps clear?
- Are required and optional instructions separated?
- Is priority defined for competing requirements?
- Are prohibited actions clearly stated?
- Is missing-information behaviour defined?
- Are subjective terms replaced with measurable rules?
- Are examples consistent with the written instructions?
- Are there any conflicting instructions?
- Can the final output be checked against clear completion criteria?
Basic Instruction-Based Prompt Template
Role: Act as [role].
Task: Perform [primary task].
Context: Use the following background information: [context].
Input: Process the following data: [input].
Required content: Include [required topics or fields].
Positive instructions: Perform [required actions].
Negative instructions: Do not perform [prohibited actions].
Conditions: If [condition], perform [action].
Sequence: First perform [step one], then perform [step two], and finally perform [step three].
Priority: Treat [requirement] as more important than [lower-priority requirement].
Behaviour: Use [tone, interaction style, or uncertainty behaviour].
Output format: Return the result as [format].
Constraints: Follow [length, language, source, technical, or scope limits].
Fallback: If [required information] is missing, return [fallback result].
Validation: Before responding, verify that [completion conditions].
Detailed Instruction-Based Prompt Template
Role:
Act as a [specific professional or functional role].
Primary task:
Complete [clearly defined main task].
Objective:
Produce a result that helps [target user] achieve [desired outcome].
Audience:
Write for [beginner, intermediate, expert, customer, manager, developer, or other audience].
Context:
Use the following background information: [relevant context].
Input:
Process the content enclosed inside the input section.
Required instructions:
Include [required item one].
Include [required item two].
Include [required item three].
Positive instructions:
Use [required approach].
Explain [required concept].
Provide [required example].
Negative instructions:
Do not invent missing information.
Do not include unrelated information.
Do not change the meaning of supplied content.
Conditional instructions:
If [condition one], perform [action one].
If [condition two], perform [action two].
Otherwise, perform [fallback action].
Sequential instructions:
First, complete [step one].
Second, complete [step two].
Third, complete [step three].
Finally, validate [result].
Priority instructions:
Priority 1: Preserve factual accuracy.
Priority 2: Complete the primary task.
Priority 3: Follow the required format.
Priority 4: Apply tone and style preferences.
Behavioural instructions:
Use clear and natural language.
Clearly identify uncertain information.
Ask for clarification only when essential information is missing.
Formatting instructions:
Return the response in [Markdown, JSON, XML, CSV, table, or another format].
Use the sections [section names].
Keep each paragraph under [number] sentences.
Constraints:
Keep the response under [word or character limit].
Use only [allowed sources or supplied information].
Use [required language].
Fallback instructions:
If a required value is missing, return [fallback value].
If the requirements conflict, follow the stated priority order.
Validation instructions:
Confirm that all required sections are present.
Confirm that no prohibited content is included.
Confirm that the output follows the required format.
Input section:
[Insert the input data here]
Practical Article-Generation Template
Role: Act as an experienced technical content writer.
Task: Create a detailed article about [topic].
Audience: Write for beginner and intermediate learners.
Introduction: Begin with a clear introduction to the topic.
Definition: Provide a simple and technically correct definition.
Core explanation: Explain how the concept works step by step.
Required content: Cover [topic one], [topic two], and [topic three].
Examples: Include at least two practical examples.
Technical example: Include one relevant code or configuration example.
Benefits: Explain the main benefits.
Limitations: Explain the main limitations.
Mistakes: Explain common mistakes and how to avoid them.
Best practices: Add a practical best-practices checklist.
Formatting: Return the article in Markdown.
Formatting: Use a level-one title and level-two topic headings.
Formatting: Add a separator between every main topic.
Style: Use simple and natural language.
Style: Explain technical terms when first used.
Constraint: Do not repeat the same explanation.
Constraint: Do not use unsupported facts.
Constraint: Do not include unrelated topics.
Validation: Confirm that every required topic has its own heading.
Practical Data-Extraction Template
Task: Extract structured information from the supplied text.
Required fields: Extract [field one], [field two], and [field three].
Format: Return valid JSON only.
Missing values: Use null when a required value is missing.
Multiple values: Return multiple values as an array.
Normalisation: Convert all dates to YYYY-MM-DD.
Source restriction: Use only information directly stated in the input.
Negative instruction: Do not infer or create missing values.
Validation: Confirm that every required field exists in the JSON object.
Input:
[Insert unstructured text here]
Practical Classification Template
Task: Classify the supplied input into exactly one category.
Allowed categories: [category one], [category two], [category three], [category four].
Category definition: [category one] means [definition].
Category definition: [category two] means [definition].
Category definition: [category three] means [definition].
Category definition: [category four] means [definition].
Priority: Select the most specific matching category.
Fallback: Use [fallback category] when no other category matches.
Format: Return only the category name.
Negative instruction: Do not create a new category.
Input:
[Insert text here]
Practical Code-Generation Template
Role: Act as a senior [programming language] developer.
Task: Create [application, class, function, API, or script].
Language: Use [language and version].
Framework: Use [framework and version].
Input: Accept [input type].
Output: Return [output type].
Required behaviour: Implement [feature one].
Required behaviour: Implement [feature two].
Required behaviour: Implement [feature three].
Validation: Reject [invalid input condition].
Error handling: Handle [expected error].
Security: Prevent [security risk].
Performance: Use [performance requirement].
Dependencies: Use only [allowed dependencies].
Structure: Create [required classes, functions, or files].
Testing: Include [unit tests, integration tests, or sample cases].
Comments: Use only useful single-line comments.
Formatting: Do not include empty lines in the code.
Formatting: Use proper indentation.
Explanation: Explain the design after the code.
Validation: Confirm that the code satisfies every listed requirement.
Complete Instruction-Based Prompt Example
Role: Act as a senior Java technical interviewer.
Task: Conduct a Java Collections Framework mock interview.
Audience: Interview a developer with three years of experience.
Content: Cover List, Set, Map, Queue, hashing, comparators, and concurrency.
Quantity: Ask ten questions.
Difficulty: Start with medium questions and gradually increase difficulty.
Sequence: Ask one question at a time.
Behaviour: Wait for the user's answer before continuing.
Behaviour: Do not reveal the answer before the user responds.
Evaluation: Rate every answer as Correct, Partially Correct, or Incorrect.
Feedback: Explain missing points using simple language.
Conditional instruction: If the answer is incorrect, provide one hint before showing the full explanation.
Priority: Evaluate technical correctness before communication style.
Final output: Provide a score out of 10 after all questions are complete.
Final output: List strong areas and topics that need revision.
Constraint: Do not repeat a question.
Constraint: Do not ask questions outside the Java Collections Framework.
This prompt is effective because it clearly defines:
- The role.
- The task.
- The target level.
- The content scope.
- The number of questions.
- The difficulty flow.
- The interaction sequence.
- The evaluation method.
- The conditional behaviour.
- The priority.
- The final output.
- The prohibited behaviour.
Advantages of Instruction-Based Prompting
- It clearly communicates the required task.
- It reduces model guessing.
- It improves output consistency.
- It supports complex workflows.
- It makes responses easier to validate.
- It supports structured output.
- It allows precise control over content.
- It supports conditional behaviour.
- It helps resolve competing requirements.
- It works for text, code, data, analysis, and conversation tasks.
- It can be reused as a template.
- It supports automated processing.
Limitations of Instruction-Based Prompting
- Very long instruction sets may become difficult to manage.
- Conflicting instructions may produce inconsistent results.
- Vague instructions still require interpretation.
- Too many restrictions can reduce response quality.
- A model may not perfectly follow every instruction.
- Required details may still be missing from the input.
- Examples may override or influence written instructions.
- Complex conditions may contain uncovered cases.
- Strict length limits may conflict with completeness.
- Prompt effectiveness may vary across models.
Instruction-based prompting improves control, but it does not guarantee perfect output. Important responses should still be reviewed and validated.
Final Summary
Instruction-based prompting directs an AI model through clear commands, rules, priorities, conditions, and output requirements.
The main instruction types are:
- Explicit instructions directly state the required action.
- Implicit instructions depend on context and common expectations.
- Positive instructions define what the model should do.
- Negative instructions define what the model should avoid.
- Priority instructions define which requirements matter most.
- Conditional instructions define actions for specific situations.
- Sequential instructions define the required order of steps.
- Behavioural instructions control interaction and communication style.
- Content instructions define the information to include.
- Formatting instructions define how the output should be structured.
- Instruction placement affects clarity and visibility.
- Conflict-resolution rules help manage incompatible requirements.
- Instruction hierarchy defines which instructions have greater authority.
An effective instruction-based prompt clearly states the task, provides relevant context, defines required content, sets boundaries, explains conditions, defines priority, and specifies a verifiable output format.
Frequently Asked Questions
What is instruction-based prompting?
Instruction-based prompting is a technique where you tell an AI model exactly what task to perform, how to perform it, and what kind of result to return, using clear commands, rules, conditions, and output requirements instead of just a topic.
What is the difference between explicit and implicit instructions?
Explicit instructions directly state the required action, audience, and format, so output is more consistent and easier to validate. Implicit instructions are only suggested by wording, role, or context - they keep prompts short but are more likely to be misunderstood.
What is the difference between positive and negative instructions?
Positive instructions define what the model should do, such as "include two examples." Negative instructions define what it must avoid, such as "do not include theory." Positive instructions should usually lead, with negative instructions reserved for important boundaries.
What are priority instructions used for?
Priority instructions tell the model which requirement matters most when instructions compete, such as accuracy over a strict word limit. They can be expressed as numbered priorities or as must/should/may labels.
How do conditional instructions work in a prompt?
Conditional instructions use if/when/otherwise logic to tell the model to perform an action only when a specific condition is true, such as "if no email address is present, return 'Email not found.'" Conditions should be clearly defined, non-overlapping, and include a fallback.
Why does instruction placement matter?
Where an instruction sits in the prompt affects how clearly the model registers it - placing the primary task and key rules near the beginning, before long input data, generally keeps them more visible than instructions buried only at the end.
What causes instruction conflicts and how can they be prevented?
Conflicts happen when two instructions cannot both be satisfied, such as requiring complete detail and a 50-word limit at the same time. They can be prevented by reviewing all requirements together, defining priority, and adding an explicit conflict-resolution rule.
What is instruction hierarchy?
Instruction hierarchy defines which instructions have more authority when sources conflict - system and developer instructions generally outrank a user prompt, and a prompt can define its own local hierarchy using must/should/may or numbered priorities.
What are common mistakes in instruction-based prompting?
Common mistakes include unclear action words, combining too many actions in one sentence, subjective requirements like "make it good," missing output format, missing fallback behaviour for missing data, and contradictory or excessive restrictions.
What are the limitations of instruction-based prompting?
Very long instruction sets can become hard to manage, conflicting or vague instructions still require interpretation, too many restrictions can reduce quality, and a model may not perfectly follow every instruction - important output should still be reviewed.