Introduction
Writing clear instructions is one of the most important skills in prompt engineering. A language model does not understand intent in the same way a human colleague does. It generates a response by interpreting the words, structure, context, constraints, and examples provided in the prompt.
When instructions are unclear, incomplete, contradictory, or overloaded with multiple objectives, the model must guess what the user expects. This often produces responses that are technically correct but unsuitable for the actual task.
A clear instruction tells the model:
- What task it must perform
- What information it should use
- What result it should produce
- How it should behave while completing the task
- What it must avoid
- When the task should be considered complete
Clear instructions reduce uncertainty and make model responses more accurate, relevant, consistent, and reusable.
Chapter Overview
This chapter explains how to design instructions that are direct, specific, measurable, and easy for a language model to follow.
It covers:
- Using direct language
- Avoiding ambiguous instructions
- Defining one primary objective
- Separating primary and secondary tasks
- Using action verbs
- Specifying required behaviour
- Specifying prohibited behaviour
- Defining completion conditions
- Removing unnecessary words
- Identifying clear prompt patterns
- Identifying ambiguous prompt patterns
- Improving unclear prompts systematically
Learning Objectives
After completing this chapter, you should be able to:
- Write instructions that communicate one clear objective
- Replace vague words with specific requirements
- Use strong action verbs to define model tasks
- Separate essential tasks from optional tasks
- Specify expected and prohibited behaviour
- Define measurable completion conditions
- Remove unnecessary wording without losing meaning
- Diagnose common clarity problems in prompts
- Convert unclear prompts into reliable instructions
Why Clear Instructions Matter
A language model processes the exact text provided in a prompt. It does not automatically know the user's hidden expectations.
Consider this instruction:
Explain Java.
The model must make several assumptions:
- Should it explain the Java language or the Indonesian island?
- Is the response for a beginner or an experienced developer?
- Should it explain syntax, history, features, architecture, or use cases?
- How long should the answer be?
- Should it include code examples?
- Should it compare Java with another language?
Now consider a clearer version:
Explain the Java programming language to a beginner.
Cover its purpose, main features, JVM architecture, and common use cases.
Include one simple Hello World example.
Keep the explanation under 700 words.
The improved prompt reduces uncertainty by defining the subject, audience, scope, required content, example, and length.
Core Principle of Clear Instruction Writing
A clear instruction should allow the model to answer the following questions without guessing:
- What action must be performed?
- What input or reference information should be used?
- What should the output contain?
- What format should the output follow?
- What rules must be followed?
- What must not be included?
- When is the task complete?
A useful basic pattern is:
Action
Subject
Scope
Requirements
Constraints
Output format
Completion condition
Example:
Summarize the provided customer feedback.
Identify the three most common complaints.
Group similar complaints together.
Include the number of mentions for each complaint.
Do not include customer names.
Present the result as a Markdown table.
Stop after listing the top three complaint categories.
Using Direct Language
What Direct Language Means
Direct language communicates the required action without unnecessary introductions, indirect requests, or conversational filler.
A direct instruction begins with the task itself.
Indirect version:
I was wondering whether you might possibly be able to create something that explains inheritance in Java.
Direct version:
Explain inheritance in Java.
The second version is easier to interpret because the required action is immediately visible.
Characteristics of Direct Instructions
Direct instructions generally:
- Begin with an action verb
- Name the subject clearly
- Avoid unnecessary politeness phrases
- Avoid hidden expectations
- Avoid vague references
- State requirements explicitly
- Use short and logically ordered sentences
Direct Language Does Not Mean Rude Language
Direct language can still be professional and respectful. The goal is not to remove politeness completely. The goal is to prevent politeness from hiding the task.
Less effective:
Could you please, if it is not too much trouble, take a look at the text below and maybe try to improve it in whatever way you think would be useful?
Clear and professional:
Improve the text below for clarity, grammar, and professional tone.
Direct Prompt Pattern
Create a technical explanation of dependency injection.
Target the explanation at junior Java developers.
Include one Spring Boot example.
Limit the response to 800 words.
Every instruction performs a specific function.
Weak and Improved Example
Weak prompt:
Can you tell me something useful about databases?
Improved prompt:
Explain relational databases to a beginner.
Cover tables, rows, columns, primary keys, and foreign keys.
Include one simple customer-order example.
Keep the response under 600 words.
Best Practices for Direct Language
- Put the main task in the first sentence
- Use one instruction per line when the prompt contains multiple rules
- Use specific nouns instead of vague pronouns
- Avoid long conversational introductions
- Avoid asking the model to guess what may be useful
- State the expected output rather than requesting general help
Avoiding Ambiguous Instructions
What Is an Ambiguous Instruction?
An ambiguous instruction can be interpreted in more than one reasonable way.
Example:
Make the response better.
The word better does not explain what must improve. It could mean:
- Shorter
- Longer
- More accurate
- More professional
- Easier to understand
- More persuasive
- Better formatted
- More detailed
Because the success criteria are undefined, the model must choose its own interpretation.
Common Sources of Ambiguity
Ambiguity commonly comes from:
- Vague adjectives
- Undefined pronouns
- Missing context
- Unclear scope
- Multiple possible subjects
- Subjective requirements
- Contradictory instructions
- Missing output format
- Missing target audience
- Missing completion conditions
Vague Words to Avoid
Words such as the following often require clarification:
- Good
- Better
- Proper
- Nice
- Useful
- Detailed
- Short
- Long
- Professional
- Simple
- Advanced
- Relevant
- Appropriate
- Optimized
- Complete
- Quickly
These words are not always wrong, but they should be supported by measurable or descriptive criteria.
Ambiguous:
Write a short explanation.
Clearer:
Write an explanation between 150 and 200 words.
Ambiguous:
Make it professional.
Clearer:
Use formal business language, complete sentences, and a neutral tone.
Ambiguous:
Explain it simply.
Clearer:
Explain the concept for a beginner who has no programming experience.
Avoid unexplained technical terminology.
Use one everyday analogy.
Avoiding Unclear Pronouns
Weak prompt:
Compare it with the previous one and explain why it is better.
The words it and previous one may not clearly identify the required items.
Improved prompt:
Compare the revised authentication design with the original session-based design.
Explain why the revised design provides better scalability and security.
Defining Scope Clearly
Weak prompt:
Explain Spring Boot completely.
The word completely creates an unlimited scope.
Improved prompt:
Explain the following Spring Boot concepts:
Auto-configuration
Starter dependencies
Embedded servers
Dependency injection
Application properties
REST controller creation
Limit the response to 1,200 words.
Replacing Subjective Requirements
Weak prompt:
Give me an impressive project description.
Improved prompt:
Write a project description suitable for a Java developer resume.
Emphasize business impact, individual contribution, Spring Boot, REST APIs, database integration, and production support.
Use five bullet points.
Begin each bullet with an action verb.
Include measurable results where data is available.
Ambiguity Detection Questions
Before submitting a prompt, ask:
- Can any important word have multiple meanings?
- Does the model know exactly what the subject is?
- Is the expected level of detail defined?
- Is the target audience identified?
- Is the output format specified?
- Are subjective words supported by criteria?
- Can the model determine when the response is finished?
Defining One Primary Objective
What Is a Primary Objective?
The primary objective is the most important result the model must produce.
Every prompt should have one clearly identifiable primary objective, even when the prompt contains several supporting requirements.
Example:
Review the Java method for potential null pointer errors.
The primary objective is code review for null pointer risks.
Supporting tasks may include:
- Identify vulnerable lines
- Explain each risk
- Suggest corrected code
- Recommend preventive practices
These tasks support the main objective instead of competing with it.
Why One Primary Objective Matters
When a prompt contains several unrelated objectives, the model may:
- Give unequal attention to tasks
- Miss one or more requirements
- Produce a disorganized response
- Mix incompatible output formats
- Prioritize the wrong request
- Generate a response that is difficult to evaluate
Overloaded Prompt Example
Explain microservices, compare them with monoliths, create Java code, review the code, make interview questions, design a project, and write a LinkedIn post.
This prompt contains several independent deliverables. Each task requires a different structure, depth, and evaluation method.
Improved Task Separation
Primary task:
Explain microservices architecture to an intermediate Java developer.
Cover service boundaries, independent deployment, communication, data ownership, and fault tolerance.
Limit the response to 1,000 words.
Separate follow-up task:
Based on the explanation, create ten microservices interview questions with answers.
Separate implementation task:
Create a Spring Boot example containing two services that communicate through REST.
How to Identify the Primary Objective
Use this sentence:
The main result I need is ________.
For example:
The main result I need is a security review of this API controller.
The prompt can then begin with:
Review the provided API controller for security vulnerabilities.
Primary Objective Formula
Main action + exact subject + intended result
Examples:
Summarize the incident report for senior management.
Refactor the method to reduce duplicate database queries.
Classify the support tickets by issue category.
Generate unit tests for the payment service.
Explain recursion to a beginner.
Compare JWT authentication with session-based authentication.
Keeping Supporting Requirements Aligned
Every secondary instruction should support the main task.
Primary objective:
Review the SQL query for performance problems.
Aligned secondary requirements:
Identify full table scans.
Identify missing indexes.
Explain expensive joins.
Provide an optimized query.
Preserve the original result set.
Unrelated secondary requirement:
Create interview questions about SQL normalization.
The unrelated task should be moved into a separate prompt.
Separating Primary and Secondary Tasks
Difference Between Primary and Secondary Tasks
A primary task defines the main deliverable.
A secondary task adds supporting work that improves, validates, formats, or explains the primary deliverable.
Example:
Primary task:
Refactor the Java method to improve readability.
Secondary tasks:
Preserve existing behaviour.
Replace duplicated logic with a helper method.
Add concise comments only where necessary.
Explain the main changes after the code.
Why Task Separation Improves Results
Explicit separation helps the model understand priority. Without it, all instructions may appear equally important.
A useful structure is:
Primary task:
Secondary tasks:
Constraints:
Output format:
Example:
Primary task:
Analyze the provided exception log and identify the most likely root cause.
Secondary tasks:
List the evidence supporting the diagnosis.
Suggest three troubleshooting steps.
Mention any assumptions.
Constraints:
Do not invent missing log entries.
Do not claim certainty when the evidence is incomplete.
Output format:
Use the sections Diagnosis, Evidence, Troubleshooting Steps, and Assumptions.
Ordering Tasks by Priority
Place instructions in this order:
- Primary objective
- Required input or context
- Secondary tasks
- Constraints
- Output format
- Completion condition
This order reflects the natural decision process required to complete the task.
Independent Tasks Should Usually Be Split
Tasks should be separated into different prompts when:
- They require unrelated expertise
- They need different output formats
- One task depends on approval of another
- Each deliverable is large
- The tasks have different audiences
- The tasks use different source material
- Failure in one task should not affect the others
Dependent Tasks Can Remain Together
Related tasks can remain in one prompt when they form a clear workflow.
Example:
Read the provided article.
Summarize its main argument.
Identify three unsupported claims.
Rewrite those claims using cautious language.
Each step depends on the previous step and contributes to one analytical objective.
Using Action Verbs
What Are Action Verbs?
Action verbs clearly define what the model must do.
Common prompt engineering action verbs include:
- Analyze
- Calculate
- Categorize
- Classify
- Compare
- Convert
- Create
- Define
- Detect
- Diagnose
- Draft
- Evaluate
- Explain
- Extract
- Generate
- Identify
- List
- Modify
- Organize
- Prioritize
- Rank
- Recommend
- Refactor
- Rewrite
- Review
- Summarize
- Translate
- Validate
- Verify
Why Action Verbs Improve Clarity
Compare the following prompts:
Weak:
Java streams.
Clear:
Explain Java streams.
More precise:
Compare Java streams with traditional loops.
Highly specific:
Refactor the provided loop using the Java Stream API while preserving its current output.
Each action verb defines a different task.
Choosing the Correct Action Verb
Different verbs imply different outputs.
Explain:
Explain how dependency injection works in Spring Boot.
Expected result: teaching-oriented description.
Summarize:
Summarize the provided Spring Boot documentation.
Expected result: condensed representation.
Compare:
Compare constructor injection with field injection.
Expected result: similarities, differences, advantages, and disadvantages.
Evaluate:
Evaluate the controller against REST API design principles.
Expected result: judgment based on criteria.
Refactor:
Refactor the controller to separate business logic from request handling.
Expected result: modified code.
Extract:
Extract all endpoint paths and HTTP methods from the controller.
Expected result: selected information only.
Avoid Weak Verb Combinations
Weak:
Take a look at the code and tell me what you think.
Clear:
Review the code for correctness, readability, performance, and security problems.
Weak:
Help me with this error.
Clear:
Diagnose the error using the stack trace and provided source code.
Identify the probable root cause.
Provide a corrected implementation.
One Action per Instruction
When possible, assign one action to each line.
Less clear:
Review and improve and explain this code and tell me whether it is production-ready.
Clearer:
Review the code for correctness and security issues.
Refactor the code to resolve confirmed problems.
Explain each significant change.
Evaluate whether the revised version is production-ready.
Specifying Required Behaviour
What Is Required Behaviour?
Required behaviour defines how the model must operate while completing the task.
The task tells the model what to produce. Behavioural instructions tell it how to produce it.
Example task:
Answer the technical questions.
Required behaviour:
Base each answer only on the provided documentation.
State when the documentation does not contain enough information.
Distinguish confirmed facts from assumptions.
Use concise technical language.
Categories of Required Behaviour
Required behaviour may define:
- Reasoning discipline
- Evidence handling
- Uncertainty handling
- Source usage
- Tone
- Audience adaptation
- Formatting
- Validation
- Error handling
- Privacy handling
- Interaction style
Evidence-Based Behaviour
Use only the information provided in the reference text.
Cite the relevant section after each conclusion.
Do not treat assumptions as confirmed facts.
State Insufficient information when the evidence is incomplete.
Accuracy-Oriented Behaviour
Verify that every method name exists in the provided code.
Preserve the original public method signatures.
Check that the revised code compiles logically.
Mention any required imports.
Audience-Oriented Behaviour
Explain each concept for a beginner.
Define technical terms before using them.
Use one practical analogy for each major concept.
Avoid assuming knowledge of machine learning.
Interaction Behaviour
Ask one clarification question only when a required input is missing.
Otherwise, complete the task using the available information.
Do not request confirmation for minor formatting decisions.
Behaviour Versus Output Requirements
Required behaviour:
Do not invent information that is not present in the source.
Output requirement:
Present the extracted information in a three-column table.
Both are useful, but they control different parts of the response.
Specifying Prohibited Behaviour
What Is Prohibited Behaviour?
Prohibited behaviour defines what the model must not do.
Negative constraints are useful when a specific unwanted behaviour is likely or harmful.
Examples:
Do not invent statistics.
Do not modify public API signatures.
Do not include personally identifiable information.
Do not use external knowledge.
Do not repeat the source text word for word.
Do not produce code that requires third-party libraries.
Why Prohibitions Matter
Without explicit prohibitions, the model may produce an otherwise reasonable response that violates an important requirement.
For example:
Summarize the customer complaint.
The model may include the customer's name, phone number, or account number.
Safer version:
Summarize the customer complaint.
Remove names, email addresses, phone numbers, account numbers, and other identifying information.
Writing Effective Prohibitions
A good prohibition should be:
- Specific
- Relevant
- Testable
- Limited to likely failure modes
- Compatible with the main task
Weak:
Do not make mistakes.
Improved:
Do not invent classes, methods, configuration properties, or dependencies that are not present in the provided project.
Weak:
Do not write badly.
Improved:
Do not use sentence fragments, unexplained abbreviations, or promotional language.
Positive and Negative Pairing
Where possible, pair a prohibition with the desired alternative.
Do not guess missing values.
Mark missing values as Not provided.
Do not return a general explanation.
Return only the corrected SQL query and a brief change summary.
Do not silently change business rules.
Preserve existing business rules and flag any required behavioural change separately.
Avoid Excessive Negative Instructions
A prompt containing too many prohibitions can become difficult to follow.
Overloaded version:
Do not be vague.
Do not be too technical.
Do not be too simple.
Do not be too long.
Do not be too short.
Do not repeat.
Do not miss anything.
Improved version:
Write 600 to 800 words for readers with basic programming knowledge.
Define advanced terms when first introduced.
Cover the six concepts listed below.
Avoid repeating the same explanation in multiple sections.
Defining Completion Conditions
What Is a Completion Condition?
A completion condition tells the model when the requested task has been fully completed.
Without a completion condition, terms such as comprehensive, complete, detailed, or exhaustive can cause inconsistent output.
Example:
Generate test cases for the login API.
This does not define how many test cases are enough or what scenarios must be covered.
Improved version:
Generate test cases for the login API.
Include successful login, invalid password, unknown user, missing fields, locked account, expired password, and rate-limit scenarios.
Provide at least one test case for each scenario.
Stop after all seven scenarios have been covered.
Types of Completion Conditions
Completion can be defined by:
- Item count
- Word count
- Section count
- Scenario coverage
- Input coverage
- Validation success
- Time range
- Ranking limit
- Required fields
- Acceptance criteria
Count-Based Conditions
Generate exactly 20 multiple-choice questions.
Include four options for each question.
Include one correct answer and one explanation for each question.
Coverage-Based Conditions
Review every public method in the class.
Report whether each method validates null input.
Complete the review only after all public methods have been assessed.
Length-Based Conditions
Write between 800 and 1,000 words.
Use no more than eight main sections.
Validation-Based Conditions
Return the final JSON only after confirming that it is syntactically valid.
Ensure every object contains id, name, status, and createdAt.
Acceptance-Criteria-Based Conditions
The task is complete when:
The revised method preserves the original output.
Duplicate database calls are removed.
Null inputs are handled.
Unit tests cover successful and unsuccessful paths.
Avoid Impossible Completion Conditions
Weak:
Explain everything about artificial intelligence.
Improved:
Explain the following foundational AI concepts:
Machine learning
Supervised learning
Unsupervised learning
Neural networks
Large language models
Generative AI
Limit each concept to one paragraph and one example.
Removing Unnecessary Words
Why Unnecessary Words Reduce Prompt Quality
Long prompts are not automatically better prompts. Extra words can hide the main instruction, introduce contradictions, waste context-window capacity, and increase interpretation difficulty.
The goal is not to make every prompt extremely short. The goal is to remove text that does not contribute to task completion.
Common Types of Unnecessary Wording
- Long greetings
- Repeated instructions
- Excessive politeness
- Irrelevant background
- Multiple versions of the same rule
- Emotional emphasis without criteria
- Generic quality requests
- Redundant adjectives
- Unnecessary self-explanation
Verbose Prompt Example
Hello, I hope you are doing well. I have been thinking about Java programming for a while, and I would really appreciate it if you could perhaps help me by creating a detailed explanation that is easy to understand and not too difficult but also useful and informative regarding exception handling in Java.
Improved version:
Explain Java exception handling to a beginner.
Cover checked exceptions, unchecked exceptions, try-catch-finally, throw, and throws.
Include one practical code example.
Use simple technical language.
Removing Repetition
Repetitive version:
Keep the answer short.
Do not make the answer long.
Be concise.
Avoid unnecessary detail.
Use as few words as possible.
Improved version:
Limit the response to 200 words.
Include only the definition, main benefits, and one example.
Remove Words Without Removing Requirements
Over-shortened prompt:
Explain JWT.
This is concise but incomplete.
Efficient and clear prompt:
Explain JWT authentication to a junior backend developer.
Cover token structure, signing, validation, expiration, and common security risks.
Include one request-response flow example.
Limit the response to 700 words.
The improved prompt is longer because it contains necessary information, not because it contains filler.
Prompt Compression Checklist
Before finalizing the prompt, remove any sentence that:
- Repeats an existing instruction
- Does not affect the output
- Contains only conversational filler
- Introduces unrelated background
- Uses several words where one precise term is sufficient
- Expresses importance without defining criteria
Clear Prompt Examples
Example 1: Technical Explanation
Explain dependency injection in Spring Boot.
Target the explanation at junior Java developers.
Cover constructor injection, field injection, and setter injection.
Explain why constructor injection is generally preferred.
Include one concise code example.
Limit the response to 800 words.
Why it is clear:
- The action is explain
- The subject is dependency injection in Spring Boot
- The audience is defined
- The scope is listed
- A preferred comparison is required
- An example is required
- The maximum length is defined
Example 2: Code Review
Review the provided Java service class.
Identify correctness, performance, security, and maintainability problems.
Reference the affected method for each problem.
Assign Critical, High, Medium, or Low severity.
Provide a corrected code example for Critical and High severity problems.
Do not invent dependencies that are not present in the project.
Present the result in a Markdown table followed by revised code.
Example 3: Data Extraction
Extract the following fields from each invoice:
Invoice number
Invoice date
Vendor name
Currency
Subtotal
Tax
Total amount
Return the result as a JSON array.
Use null when a field is missing.
Do not calculate values that are not explicitly shown.
Preserve the original currency notation.
Example 4: Content Summarization
Summarize the provided incident report for senior management.
Focus on business impact, root cause, recovery actions, and preventive measures.
Exclude low-level debugging details.
Use the sections Executive Summary, Impact, Cause, Resolution, and Prevention.
Limit the response to 500 words.
Example 5: SQL Optimization
Analyze the provided SQL query for performance problems.
Identify unnecessary joins, full table scans, inefficient filters, and missing indexes.
Provide an optimized query that returns the same result set.
Explain each significant change.
Do not change the business logic.
Mention any assumptions about table size or indexing.
Example 6: Interview Question Generation
Generate exactly 15 Java multithreading interview questions.
Create five easy, five medium, and five hard questions.
Provide a concise answer and practical explanation for each question.
Avoid duplicate concepts.
Cover thread lifecycle, synchronization, locks, executors, race conditions, deadlocks, and virtual threads.
Number the questions from 1 to 15.
Example 7: API Design
Design REST endpoints for an online course enrollment system.
Include course listing, course details, enrollment creation, enrollment cancellation, and enrollment history.
Specify the HTTP method, endpoint path, request body, response body, and expected status codes.
Use resource-oriented endpoint names.
Do not include authentication implementation.
Present the result in a Markdown table.
Example 8: Rewrite Task
Rewrite the provided email in a professional and respectful tone.
Preserve all dates, names, amounts, and requested actions.
Remove emotional or accusatory wording.
Keep the email between 150 and 200 words.
Return only the revised email.
Ambiguous Prompt Examples
Example 1
Write about Java.
Problems:
- No specific action beyond write
- No defined topic within Java
- No target audience
- No length
- No required format
- No purpose
Example 2
Make this code better.
Problems:
- Better is subjective
- No quality criteria
- No indication of whether behaviour may change
- No programming-language version
- No expected output structure
Example 3
Create some interview questions.
Problems:
- Topic is missing
- Number of questions is missing
- Difficulty is missing
- Answer requirement is missing
- Audience and experience level are missing
Example 4
Explain it properly.
Problems:
- The subject identified by it may be unclear
- Properly is undefined
- Depth and audience are unknown
- Required examples are unknown
Example 5
Give me a complete tutorial.
Problems:
- Topic is missing
- Complete has no measurable boundary
- Format is missing
- Reader level is missing
- Practical requirements are missing
Example 6
Check whether this is correct.
Problems:
- The validation criteria are unknown
- The expected response type is unknown
- It is unclear whether corrections are required
- It is unclear whether external assumptions are allowed
Example 7
Make it short but detailed.
Problems:
- Short and detailed can conflict
- No word limit is provided
- No priority is defined
- Required details are not listed
Example 8
Analyze the data and do the needful.
Problems:
- Analysis objective is missing
- Relevant metrics are missing
- Do the needful does not define an action
- Expected output is missing
- Completion conditions are missing
Improving Unclear Prompts
A Systematic Improvement Process
An unclear prompt can be improved through the following steps.
Step 1: Identify the Main Action
Ask:
- What exactly should the model do?
Replace general requests with a specific action verb.
Unclear:
Help with this Java code.
Improved action:
Review this Java code.
More specific action:
Diagnose why this Java code throws a NullPointerException.
Step 2: Identify the Exact Subject
Ask:
- What object, text, code, dataset, or concept should the model process?
Unclear:
Explain this.
Improved:
Explain the purpose of the synchronized keyword in the provided Java method.
Step 3: Define the Desired Result
Ask:
- What result should the user receive?
Unclear:
Analyze the logs.
Improved:
Analyze the logs and identify the most likely cause of the database connection failure.
Step 4: Define Scope
Ask:
- Which parts should be included?
- Which parts should be excluded?
Improved scope:
Focus on connection-pool exhaustion, database availability, authentication failure, timeout settings, and network errors.
Step 5: Add Required Behaviour
Ask:
- How should the model handle evidence, uncertainty, missing information, or assumptions?
Example:
Base the diagnosis only on the provided logs.
Distinguish confirmed evidence from possible causes.
State when additional information is required.
Step 6: Add Prohibited Behaviour
Ask:
- What likely unwanted behaviour must be prevented?
Example:
Do not invent log entries.
Do not claim a root cause as confirmed without supporting evidence.
Step 7: Define Output Format
Ask:
- How should the response be organized?
Example:
Use the sections Most Likely Cause, Supporting Evidence, Alternative Causes, and Next Checks.
Step 8: Define Completion Conditions
Ask:
- How will the user know that the task is complete?
Example:
Provide one primary diagnosis, up to three alternative causes, and five ordered troubleshooting steps.
Step 9: Remove Redundant Wording
Delete:
- Repeated requirements
- Filler phrases
- Irrelevant context
- Unmeasurable quality claims
Complete Improvement Example
Original prompt:
Check my API and tell me if it is good and make it secure.
Problems:
- Check is too broad
- Good is subjective
- The security scope is undefined
- No expected output is defined
- It is unclear whether code should be changed
- No technology or threat model is identified
Improved prompt:
Review the provided Spring Boot REST controller for security vulnerabilities.
Check authentication, authorization, input validation, sensitive-data exposure, exception handling, injection risks, and insecure logging.
Identify the affected endpoint and code location for each issue.
Assign Critical, High, Medium, or Low severity.
Explain the security impact of each confirmed issue.
Provide corrected code for Critical and High severity issues.
Preserve existing endpoint paths and response contracts.
Do not invent project configuration that is not provided.
Present findings in a Markdown table followed by revised code.
The review is complete after every public endpoint has been assessed.
Before-and-After Prompt Transformations
Transformation 1: Explanation Request
Before:
Explain microservices nicely.
After:
Explain microservices architecture to an intermediate Java developer.
Cover service boundaries, independent deployment, inter-service communication, decentralized data ownership, service discovery, fault tolerance, and observability.
Include one e-commerce example.
Explain two advantages and two disadvantages.
Limit the response to 1,000 words.
Transformation 2: Code Improvement
Before:
Optimize this method.
After:
Optimize the provided Java method to reduce database calls and unnecessary object creation.
Preserve its public signature and current result.
Do not introduce third-party libraries.
Explain the time and space complexity before and after optimization.
Return the revised method followed by a concise explanation.
Transformation 3: Content Generation
Before:
Write a blog about prompt engineering.
After:
Write a beginner-friendly article titled Introduction to Prompt Engineering.
Explain what a prompt is, how language models interpret instructions, why context matters, and how constraints improve output.
Include three weak-versus-improved prompt examples.
Use Markdown headings and bullet points.
Write between 1,200 and 1,500 words.
Avoid promotional claims and unnecessary repetition.
Transformation 4: Question Generation
Before:
Give Java questions.
After:
Generate exactly 20 Java Collections Framework interview questions.
Include eight easy, seven medium, and five hard questions.
Provide a concise answer and practical explanation for each question.
Cover List, Set, Queue, Map, iterators, sorting, concurrency, and performance.
Do not repeat the same concept.
Number the questions from 1 to 20.
Transformation 5: Error Diagnosis
Before:
Why is this not working?
After:
Diagnose why the provided Spring Boot application fails during startup.
Use the stack trace, configuration, and source code provided below.
Identify the most likely root cause.
Quote the relevant error message.
Provide ordered correction steps.
Mention any missing information that prevents a confirmed diagnosis.
Do not suggest unrelated configuration changes.
Practical Prompt Template
The following template can be adapted for technical, business, educational, analytical, or creative tasks.
Primary task:
Perform [action] on [subject].
Objective:
Produce [specific result].
Context:
Use the following background information: [context].
Required content:
Include [required item 1].
Include [required item 2].
Include [required item 3].
Required behaviour:
Follow [behaviour rule 1].
Follow [behaviour rule 2].
Prohibited behaviour:
Do not [prohibited action 1].
Do not [prohibited action 2].
Output format:
Present the result as [format].
Completion condition:
The task is complete when [measurable condition].
Technical Prompt Example
Java Code Review Prompt
Primary task:
Review the provided Java payment service for correctness and reliability problems.
Required checks:
Check null handling.
Check transaction boundaries.
Check duplicate payment risks.
Check exception handling.
Check thread-safety.
Check sensitive-data logging.
Required behaviour:
Reference the affected method for every finding.
Distinguish confirmed defects from possible risks.
Preserve the existing public API.
Prohibited behaviour:
Do not invent classes or configuration not included in the input.
Do not change business rules without explicitly identifying the change.
Output format:
Present findings in a Markdown table.
Include severity, location, problem, impact, and recommendation.
Provide revised code after the table.
Completion condition:
Complete the review after assessing every public method.
Expected Response Structure
Summary
Findings Table
Revised Code
Assumptions
Remaining Risks
Why This Prompt Is Effective
- It defines one primary objective
- It provides a concrete review scope
- It specifies evidence-handling behaviour
- It prevents invented project details
- It preserves public interfaces
- It defines an exact output structure
- It includes a measurable completion condition
Business Prompt Example
Customer Feedback Analysis
Analyze the provided customer feedback from the last quarter.
Identify the five most frequently mentioned problems.
Group semantically similar complaints into one category.
Count the number of comments in each category.
Include one representative paraphrased example for each category.
Do not include customer names or contact information.
Do not invent causes that are not stated in the feedback.
Present the result in a table ordered by frequency.
End with three recommended product actions based on the findings.
The analysis is complete after all feedback records have been classified.
Educational Prompt Example
Beginner-Level Explanation
Explain recursion to a learner with basic knowledge of variables, methods, and conditional statements.
Define recursion and base case.
Explain how the call stack behaves.
Include one everyday analogy.
Include one Java factorial example.
Trace the execution for factorial of 4.
Mention infinite recursion and stack overflow.
Avoid advanced mathematical terminology.
Limit the response to 900 words.
Clear Instruction Design Checklist
Before using a prompt, verify the following points.
Objective
- Does the prompt contain one primary objective?
- Is the main task written near the beginning?
- Does the objective use a precise action verb?
Subject and Context
- Is the subject clearly identified?
- Is all required background information included?
- Are references such as this, it, or previous one unambiguous?
Scope
- Are required topics listed?
- Are exclusions identified?
- Is the level of detail defined?
- Is the target audience stated where relevant?
Behaviour
- Does the prompt define how uncertainty should be handled?
- Does it specify whether external knowledge may be used?
- Does it define how assumptions should be reported?
- Does it require validation where necessary?
Prohibitions
- Are important unwanted behaviours explicitly prohibited?
- Are prohibitions specific and testable?
- Are there too many negative instructions?
Output
- Is the output format defined?
- Are required sections or fields listed?
- Is the expected length or item count specified?
- Is the language or tone defined where necessary?
Completion
- Can the model determine when the task is complete?
- Are all required scenarios or input items covered?
- Are acceptance criteria measurable?
Efficiency
- Has repeated wording been removed?
- Has irrelevant background been removed?
- Are instructions arranged in logical order?
- Is each important instruction easy to identify?
Common Mistakes
Mistake 1: Assuming the Model Knows the Context
Weak:
Continue the project explanation.
Unless the previous context is clearly available, the model may not know which project or which section should continue.
Improved:
Continue the explanation of the online payment project from the API Integration section.
Cover payment initiation, callback validation, retry handling, and reconciliation.
Mistake 2: Using Quality Words Without Criteria
Weak:
Create high-quality questions.
Improved:
Create questions that test conceptual understanding, practical application, debugging ability, and production experience.
Avoid definition-only questions.
Mistake 3: Combining Conflicting Requirements
Weak:
Explain every detail in fewer than 100 words.
Improved:
Summarize the three most important points in fewer than 100 words.
Mistake 4: Hiding the Main Task
Weak:
I am preparing for an interview next month, and I have worked with Java for several years, and I have read many questions, but I need some help because interviews can be difficult, so perhaps you can create questions about concurrency.
Improved:
Generate 20 Java concurrency interview questions for a developer with three years of experience.
Focus on practical debugging and production scenarios.
Mistake 5: Failing to Define the Output
Weak:
Analyze this code.
Improved:
Analyze this code for defects.
Return a table containing line reference, defect, impact, severity, and correction.
Mistake 6: Repeating the Same Rule
Weak:
Be concise.
Keep it short.
Do not make it long.
Avoid excessive details.
Improved:
Limit the response to 300 words.
Mistake 7: Using Too Many Independent Objectives
Weak:
Explain REST APIs, generate code, test it, create questions, and write social media content.
Improved:
First prompt: Explain REST API design principles.
Second prompt: Generate a Spring Boot implementation.
Third prompt: Create test cases for the implementation.
Fourth prompt: Generate interview questions from the completed example.
Advanced Clarity Techniques
Use Explicit Priority Labels
When several requirements exist, identify priority.
Highest priority:
Preserve the current business behaviour.
Required:
Remove duplicate queries.
Improve null handling.
Optional:
Suggest naming improvements.
Define Tie-Breaking Rules
Sometimes two requirements may conflict.
Prioritize factual accuracy over brevity.
When required details exceed the target length, exceed the limit rather than omit critical safety information.
Define Missing-Information Behaviour
When a required value is unavailable, use Not provided.
Do not estimate or infer missing financial figures.
Define Assumption Behaviour
List assumptions before using them.
Do not use assumptions that materially change the business logic.
Request clarification when a missing fact prevents a reliable answer.
Define Transformation Boundaries
Correct grammar and improve readability.
Preserve the original meaning, dates, names, amounts, and commitments.
Do not add new promises or claims.
Define Source Boundaries
Use only the supplied policy document.
Do not use general legal knowledge.
Cite the relevant section for each answer.
Measuring Instruction Clarity
Prompt clarity can be evaluated using six practical dimensions.
Specificity
Does the prompt clearly identify the task, subject, audience, and scope?
Interpretability
Can the instruction be understood in only one reasonable way?
Testability
Can the output be checked against explicit requirements?
Completeness
Does the prompt contain all information needed to perform the task?
Consistency
Do all instructions support each other without conflict?
Efficiency
Does every sentence contribute to the required result?
A strong prompt performs well across all six dimensions.
Final Example of a Complete Clear Prompt
Role:
Act as a senior Java code reviewer.
Primary task:
Review the provided Spring Boot order service for reliability and maintainability problems.
Context:
The service creates orders, reserves inventory, processes payment, and publishes an order-created event.
Required checks:
Check transaction consistency.
Check duplicate order prevention.
Check payment failure handling.
Check inventory rollback.
Check exception handling.
Check thread-safety.
Check logging of sensitive information.
Required behaviour:
Base findings only on the provided code.
Distinguish confirmed defects from possible risks.
Explain the business impact of each issue.
Reference the affected class and method.
Prohibited behaviour:
Do not invent missing infrastructure.
Do not change public API contracts.
Do not silently change business rules.
Output format:
Start with a five-sentence executive summary.
Present findings in a Markdown table.
Use the columns Severity, Location, Finding, Impact, and Recommendation.
Provide revised code for Critical and High severity findings.
End with a list of assumptions and unresolved risks.
Completion condition:
The review is complete after every public method and every external interaction have been assessed.
Key Takeaways
- Clear instructions begin with a precise action
- Direct language reduces unnecessary interpretation
- Ambiguous words should be replaced with measurable requirements
- Every prompt should have one identifiable primary objective
- Secondary tasks should support the primary objective
- Independent deliverables should usually be separated
- Action verbs define the exact operation the model must perform
- Required behaviour controls how the model completes the task
- Prohibited behaviour prevents predictable failure modes
- Completion conditions define when enough work has been done
- Necessary detail improves prompts, while filler weakens them
- Output format, scope, audience, and constraints should be explicit
- A clear prompt should be easy to understand, execute, and evaluate
Conclusion
Writing clear instructions is the foundation of reliable prompt engineering. A model performs best when it receives a specific objective, defined scope, explicit behavioural rules, measurable output requirements, and a clear completion condition.
The purpose of a well-written prompt is not to control every word of the response. Its purpose is to remove unnecessary uncertainty while preserving enough flexibility for the model to produce a useful result.
The most effective instructions are direct but complete, concise but specific, and detailed only where the details influence the output. By using precise action verbs, separating tasks, defining expected and prohibited behaviour, and removing ambiguity, prompt engineers can consistently obtain responses that are more accurate, relevant, structured, and dependable.
Frequently Asked Questions
Why is writing clear instructions important in prompt engineering?
A language model interprets only the words, structure, context, constraints, and examples in a prompt. Unclear, incomplete, or contradictory instructions force the model to guess, which often produces technically correct but unsuitable responses.
What questions should a clear instruction let the model answer without guessing?
A clear instruction should define what action must be performed, what input or reference to use, what the output should contain, what format to follow, what rules to obey, what must not be included, and when the task is complete.
What is direct language in a prompt?
Direct language communicates the required action without unnecessary introductions, indirect requests, or conversational filler. A direct instruction begins with the task itself, such as "Explain inheritance in Java" instead of a long indirect request.
Does direct language mean the prompt has to sound rude?
No. Direct language can still be professional and respectful. The goal is not to remove politeness, but to prevent politeness from hiding the actual task the model needs to perform.
What makes an instruction ambiguous?
An instruction is ambiguous when it can be reasonably interpreted in more than one way, often because of vague adjectives, undefined pronouns, missing context, unclear scope, or missing output format, audience, or completion conditions.
Which words commonly create ambiguity in prompts?
Words such as good, better, proper, nice, useful, detailed, short, long, professional, simple, advanced, relevant, appropriate, optimized, complete, and quickly often require clarification through measurable or descriptive criteria.
What is a primary objective in a prompt?
The primary objective is the single most important result the model must produce. Every prompt should have one clearly identifiable primary objective, even when it also contains several supporting or secondary requirements.
Why should primary and secondary tasks be separated?
Explicit separation helps the model understand priority. Without it, all instructions may appear equally important, which can cause unequal attention to tasks, missed requirements, or a disorganized response.
When should independent tasks be split into separate prompts?
Tasks should usually be split when they require unrelated expertise, need different output formats, depend on approval of another task, are each large, target different audiences, or use different source material.
Why do action verbs matter in prompt instructions?
Action verbs such as explain, summarize, compare, evaluate, refactor, and extract clearly define what the model must do. Different verbs imply different expected outputs, so choosing the correct one reduces ambiguity.
What is required behaviour in a prompt?
Required behaviour defines how the model must operate while completing the task, such as evidence handling, uncertainty handling, source usage, tone, audience adaptation, and error handling, separate from what the task itself asks for.
What is prohibited behaviour and why is it useful?
Prohibited behaviour defines what the model must not do, such as inventing statistics or including personally identifiable information. Explicit prohibitions prevent an otherwise reasonable response from violating an important requirement.
Can a prompt have too many negative instructions?
Yes. A prompt containing too many prohibitions can become difficult to follow. It is usually better to combine a few specific, testable prohibitions with positive instructions that state the desired alternative.
What is a completion condition?
A completion condition tells the model when a task has been fully completed, using item count, word count, scenario coverage, validation success, or acceptance criteria, instead of vague terms like comprehensive or exhaustive.
Why should unnecessary words be removed from a prompt?
Long prompts are not automatically better. Extra words can hide the main instruction, introduce contradictions, waste context-window capacity, and increase interpretation difficulty, without adding real value to the task.
Does removing unnecessary words mean the prompt should always be short?
No. The goal is to remove text that does not contribute to task completion, not to minimize length at all costs. A necessary detail such as audience, scope, or examples should stay even if it makes the prompt longer.
What is the systematic process for improving an unclear prompt?
Identify the main action, identify the exact subject, define the desired result, define scope, add required behaviour, add prohibited behaviour, define output format, define completion conditions, and remove redundant wording.
What are common mistakes when writing prompt instructions?
Common mistakes include assuming the model knows unstated context, using quality words without criteria, combining conflicting requirements, hiding the main task in a long message, failing to define the output, and repeating the same rule.
What six dimensions can be used to measure instruction clarity?
Instruction clarity can be evaluated using specificity, interpretability, testability, completeness, consistency, and efficiency. A strong prompt performs well across all six dimensions.
What is a practical template for writing a clear prompt?
A practical template defines the primary task, objective, context, required content, required behaviour, prohibited behaviour, output format, and completion condition, in that order, so the model receives execution requirements progressively.