Defining the Task and Intent

Introduction

A prompt becomes effective only when it clearly communicates what the user wants the AI system to accomplish. This begins with two closely related elements: intent and task definition.

Intent describes the user's actual goal or desired outcome. The task describes the specific action the model must perform to achieve that goal.

For example, a user may write:

Explain Java interfaces.

The visible task is to explain Java interfaces. However, the underlying intent may differ:

• Learn the concept for the first time
• Prepare for an interview
• Understand how interfaces differ from abstract classes
• Generate study notes
• Solve a programming problem
• Review existing knowledge

An effective prompt identifies both the required action and the purpose behind it. When the task and intent are clearly defined, the model can select appropriate information, depth, structure, tone, examples, and output format.

Poorly defined tasks often produce responses that are technically correct but practically unusable. The response may be too broad, too short, too advanced, incorrectly formatted, or focused on the wrong objective.

This chapter explains how to identify user intent, define primary and secondary tasks, set task boundaries, specify input and output expectations, handle missing information, resolve conflicting requirements, and create reusable task-definition templates.

Learning Objectives

After completing this chapter, you should be able to:

• Identify the explicit and implicit intent behind a request
• Convert a general goal into a clearly defined task
• Separate primary tasks from secondary tasks
• Decide when to use single-task or multi-task prompts
• Assign priorities to multiple instructions
• Define clear task boundaries
• Establish measurable completion criteria
• Specify the input the model should process
• Define the expected output structure
• Handle incomplete or missing information
• Resolve conflicting prompt requirements
• Build prompts using a structured task-definition template

Key Terminology

Understanding Task and Intent

Task and intent are related, but they are not identical.

The task answers:

What should the model do?

The intent answers:

Why does the user want this task completed?

Consider the following prompt:

Review this Java code.

The task is code review. However, the intent is unclear. The user may want the model to:

• Find bugs
• Improve performance
• Check security
• Improve readability
• Prepare the code for production
• Explain the code to a beginner
• Verify compliance with coding standards

A stronger prompt defines both elements:

Review the following Java code for logical errors, performance issues, null-safety problems, and maintainability concerns.
Explain each issue in simple language.
Provide a corrected version of the code.
Target the explanation toward an intermediate Java developer.

The revised prompt gives the model a clear operational objective and enough context to produce a useful result.

Identifying User Intent

User intent represents the result the user actually wants from the interaction. It may be directly stated or indirectly implied.

Explicit Intent

Explicit intent is clearly written in the prompt.

Example:

Create ten Java interview questions about exception handling for developers with two years of experience.

The intent is explicit:

• Generate interview questions
• Focus on Java exception handling
• Target developers with two years of experience
• Produce exactly ten questions

Implicit Intent

Implicit intent must be inferred from context.

Example:

I have a Java interview tomorrow. Explain exception handling.

The direct task is to explain exception handling. The likely intent is interview preparation.

A useful response should therefore emphasize:

• Frequently asked interview concepts
• Checked and unchecked exceptions
• try, catch, finally, throw, and throws
• Custom exceptions
• Common interview traps
• Practical code examples

Operational Intent

Operational intent describes what the user plans to do with the response.

Examples include:

• Publish the content on a website
• Submit an assignment
• Send an email
• Prepare for an interview
• Debug an application
• Generate training material
• Create structured data for software
• Make a business decision

Knowing how the response will be used helps the model choose the correct level of detail, formatting, and terminology.

Intent Identification Process

Use the following process to identify user intent:

1. Identify the action verb.
2. Identify the subject or object of the task.
3. Determine the expected result.
4. Identify the target audience.
5. Examine available context.
6. Determine how the output will be used.
7. Identify constraints and success conditions.
8. Look for missing information that could change the answer.

Common Action Verbs and Their Intent

Intent Identification Example

Weak prompt:

Tell me about Spring Boot.

Possible interpretations include:

• Provide a beginner introduction
• Explain Spring Boot architecture
• Prepare interview notes
• Compare Spring Boot with Spring Framework
• Build a REST API
• Describe production deployment

Improved prompt:

Explain Spring Boot to a Java developer who understands basic Spring concepts.
Focus on auto-configuration, starter dependencies, embedded servers, dependency injection, and production-ready features.
Include one practical REST API example.
Keep the explanation suitable for interview preparation.

The improved prompt removes uncertainty about the intended outcome.

Defining the Primary Task

The primary task is the most important action the model must complete. Every prompt should have one clearly identifiable primary task, even when multiple supporting instructions are included.

Characteristics of a Strong Primary Task

A strong primary task is:

• Specific
• Actionable
• Unambiguous
• Relevant to the user's goal
• Possible to complete with the available input
• Verifiable through completion criteria

Weak Primary Task

Help me with Java.

This prompt does not define a concrete action.

Improved Primary Task

Explain Java multithreading and show how to create threads using the Thread class, Runnable interface, and ExecutorService.

The improved task identifies:

• The subject: Java multithreading
• The action: Explain
• The required coverage: Three thread-creation approaches

Primary Task Formula

A useful primary-task formula is:

Action + Subject + Scope + Purpose

Example:

Analyze the following SQL query for performance problems and recommend indexing improvements for a PostgreSQL database.

Breakdown:

• Action: Analyze
• Subject: SQL query
• Scope: Performance problems and indexing
• Purpose: Improve PostgreSQL query performance

Primary Task Example

# Primary task
Review the provided Java service class for logical errors, thread-safety problems, and maintainability issues.
# Required result
Return a corrected version with an explanation of every important change.

Each instruction is separate and directly executable.

Defining Secondary Tasks

Secondary tasks support the primary task but are not the main objective.

Examples of secondary tasks include:

• Adding examples
• Formatting the response
• Explaining reasoning
• Highlighting risks
• Suggesting improvements
• Providing a summary
• Adding a checklist
• Classifying findings by severity

Consider this prompt:

Review the following Java code for security vulnerabilities.
Classify each issue as critical, high, medium, or low.
Explain how each vulnerability could be exploited.
Provide corrected code.
End with a security checklist.

The tasks are:

Primary task

• Review the code for security vulnerabilities

Secondary tasks

• Classify vulnerability severity
• Explain exploitation risks
• Provide corrected code
• Add a security checklist

Why Primary and Secondary Tasks Must Be Separated

When every instruction appears equally important, the model may:

• Spend too much effort on formatting
• Neglect the main analysis
• Produce a summary before completing the task
• Prioritize minor requirements over core accuracy
• Return an unbalanced response

A prompt should clearly state which task is mandatory and which tasks are supporting requirements.

Secondary Task Example

# Primary task
Explain dependency injection in Spring Boot.
# Secondary task
Compare constructor injection with field injection.
# Secondary task
Include one practical service-layer example.
# Secondary task
End with five interview questions.

This structure makes the instruction hierarchy visible.

Single-Task Prompts

A single-task prompt asks the model to complete one main action.

Example:

Summarize the following article in 150 words.

Single-task prompts are useful when:

• Accuracy is more important than breadth
• The task is independent
• The user needs a predictable response
• The output will be processed by software
• The instruction should be easy to test
• The task is part of a larger workflow

Advantages of Single-Task Prompts

• Lower ambiguity
• Easier evaluation
• More consistent output
• Reduced risk of skipped instructions
• Easier debugging
• Better suitability for automation
• Clearer completion criteria

Single-Task Prompt Example

Extract all email addresses from the provided text.
Return only unique email addresses.
Place one email address on each line.
Do not include explanations.

Although the prompt contains several instructions, it still has one primary task: extracting email addresses.

When to Split a Prompt into Multiple Single Tasks

Split a prompt when:

• Each task requires a different reasoning process
• One task depends on the result of another
• The combined prompt is difficult to evaluate
• The output is too large
• Different tasks require different formats
• Failure in one task could affect all other tasks
• The tasks have different priorities

For example, instead of writing:

Analyze this business proposal, rewrite it, create a presentation, generate social media posts, and prepare an email campaign.

Use separate stages:

1. Analyze the proposal.
2. Rewrite the proposal.
3. Build a presentation outline.
4. Generate social posts.
5. Create an email campaign.

This staged approach improves control and output quality.

Multi-Task Prompts

A multi-task prompt asks the model to complete several related actions within one interaction.

Example:

Analyze the following customer feedback.
Group the comments by topic.
Identify positive and negative sentiment.
List the three most common complaints.
Recommend product improvements.

The tasks are related because they operate on the same input and contribute to one broader objective.

When Multi-Task Prompts Are Appropriate

Use a multi-task prompt when:

• Tasks use the same input
• Tasks contribute to one larger goal
• The required output is manageable
• Dependencies between tasks are clear
• The task order can be defined
• The output format can represent all results clearly

Risks of Multi-Task Prompts

Multi-task prompts may cause:

• Skipped instructions
• Incorrect task order
• Shallow analysis
• Inconsistent formatting
• Excessively long responses
• Confusion about priorities
• Partial completion

Designing an Effective Multi-Task Prompt

A good multi-task prompt should:

1. State the main objective.
2. Number the tasks.
3. Define the execution order.
4. Assign priorities.
5. Define the output structure.
6. Explain dependencies.
7. Set completion criteria.

Multi-Task Prompt Example

# Main objective
Evaluate the following Java REST API implementation for production readiness.
# Task 1
Identify functional and logical defects.
# Task 2
Identify security vulnerabilities.
# Task 3
Identify performance and scalability risks.
# Task 4
Recommend improvements in priority order.
# Task 5
Provide corrected code for critical issues.
# Output order
Present the response in the same order as the tasks.
# Completion condition
Do not mark the review complete until every task has been addressed.

The numbered structure helps the model process each requirement systematically.

Single-Task Prompts vs Multi-Task Prompts

Task Prioritisation

Task prioritisation tells the model which instructions matter most.

Without priorities, the model may treat every requirement equally, even when some requirements are critical and others are optional.

Common Priority Levels

A practical priority system is:

1. Mandatory
2. High priority
3. Supporting
4. Optional

Priority Example

# Mandatory requirement
Identify all security vulnerabilities that could expose customer data.
# High-priority requirement
Recommend a fix for each vulnerability.
# Supporting requirement
Classify each issue by severity.
# Optional requirement
Suggest additional security tools that could detect similar problems.

This prevents the model from spending excessive effort on optional recommendations while missing critical vulnerabilities.

Priority by Execution Order

Priority can also be established through order:

First, validate the input data.
Second, identify invalid records.
Third, calculate totals using only valid records.
Finally, produce a summary report.

The calculation depends on validation, so the task order is operationally important.

Priority Keywords

Useful priority phrases include:

• The primary objective is
• This requirement is mandatory
• Complete this before proceeding
• Prioritize accuracy over brevity
• If requirements conflict, follow
• Treat this as optional
• Do not skip
• Perform only after
• Use the following priority order

Priority Resolution Rule

A prompt may include a conflict-resolution instruction:

If brevity conflicts with technical completeness, prioritize technical completeness.
If formatting conflicts with correctness, prioritize correctness.
If required information is unavailable, state the limitation instead of inventing details.

These rules tell the model how to make decisions when every instruction cannot be satisfied perfectly.

Task Boundaries

Task boundaries define the permitted scope of the model's work. They prevent the response from becoming too broad, irrelevant, speculative, or unsafe.

A task boundary answers:

• What should be included?
• What should be excluded?
• What assumptions are allowed?
• What sources may be used?
• How far should the model extend the analysis?
• When should the model stop?

Inclusion Boundaries

Inclusion boundaries define required coverage.

Example:

Cover only Java 17 features related to records, sealed classes, pattern matching, and text blocks.

Exclusion Boundaries

Exclusion boundaries define what must not be included.

Example:

Do not discuss preview features or features introduced after Java 17.

Knowledge Boundaries

Knowledge boundaries control whether the model may use external or inferred information.

Example:

Base the answer only on the supplied project documentation.
Do not introduce assumptions that are not supported by the document.

Action Boundaries

Action boundaries define what the model may do.

Example:

Review the code and recommend changes.
Do not rewrite the complete application.

Length Boundaries

Length boundaries control response size.

Example:

Limit the explanation to 800 words.
Use no more than three examples.

Audience Boundaries

Audience boundaries define the expected knowledge level.

Example:

Write for developers who understand Java syntax but have not used concurrency APIs.

Task Boundary Example

# Include
Explain Java HashMap internals, hashing, buckets, collisions, resizing, and time complexity.
# Exclude
Do not explain every Map implementation.
# Audience
Write for intermediate Java developers.
# Length
Keep the article between 1200 and 1500 words.
# Scope restriction
Use Java 8 or later behavior only.

Clear boundaries keep the response focused and relevant.

Task Completion Criteria

Completion criteria define the conditions that must be satisfied before the task can be considered finished.

A weak prompt says:

Review this code.

A stronger prompt says:

Review the code and identify every logical error, null-safety issue, resource leak, and concurrency problem.
For each issue, provide its location, severity, explanation, and recommended correction.
Finish only after all methods have been reviewed.

The stronger prompt defines measurable completion conditions.

Characteristics of Good Completion Criteria

Completion criteria should be:

• Observable
• Specific
• Measurable
• Relevant
• Realistic
• Connected to the expected output

Common Completion Criteria

A task may be considered complete when:

• Every input item has been processed
• Every required section is included
• All identified issues have explanations
• The response follows the requested format
• Required examples are present
• The output satisfies length requirements
• Missing information is clearly identified
• No prohibited content is included
• A final validation check has been performed

Completion Criteria Example

# Completion criteria
Process every record in the input.
List every invalid record with a reason.
Calculate the total number of valid and invalid records.
Provide a corrected version of each invalid record.
Return the final result as valid JSON.
Do not include any text outside the JSON object.

This prompt is easy to evaluate because each completion condition is testable.

Definition of Done

In complex prompts, completion criteria can be written as a definition of done.

# Definition of done
The explanation covers all listed concepts.
Every concept includes one practical example.
The comparison table contains at least five differences.
The final checklist contains actionable validation points.
The response contains no unsupported assumptions.

Expected Input

Expected input describes the data the model will receive and how it should interpret that data.

Input may include:

• Natural-language text
• Source code
• Structured JSON
• CSV records
• Database queries
• Logs
• Images
• Tables
• Requirements
• Customer feedback
• Product specifications
• Business documents

Why Expected Input Must Be Defined

If the input is unclear, the model may:

• Interpret examples as instructions
• Treat metadata as content
• Process only part of the data
• Use the wrong data format
• Confuse multiple documents
• Invent missing fields
• Apply incorrect assumptions

Input Definition Components

An input definition should specify:

• Input type
• Input format
• Required fields
• Optional fields
• Delimiters
• Data meaning
• Valid value ranges
• How to handle invalid data
• Whether all records must be processed

Expected Input Example

# Expected input
The input is a JSON array of customer-support tickets.
Each ticket contains id, subject, description, priority, and createdAt.
The priority value must be low, medium, high, or critical.
Treat missing descriptions as incomplete records.
Process every ticket in the array.

Input Delimiters

Delimiters separate instructions from the data being processed.

Analyze the customer complaint provided between the INPUT markers.
INPUT START
The application crashes whenever I upload a file larger than 10 MB.
INPUT END
Identify the problem, impact, urgency, and recommended next action.

Delimiters reduce the risk that input content will be mistaken for prompt instructions.

Input Validation Instructions

A reliable prompt should explain what to do with invalid input.

Validate the input before performing the analysis.
If a required field is missing, mark the record as invalid.
Do not invent values for missing fields.
Continue processing the remaining valid records.

Expected Output

Expected output defines how the result should be presented.

A good output definition may specify:

• Format
• Structure
• Required sections
• Field names
• Data types
• Length
• Tone
• Ordering
• Level of detail
• Whether explanations are allowed
• Whether additional text is prohibited

Common Output Formats

• Markdown article
• Plain text
• JSON
• XML
• CSV
• HTML
• Table
• Bullet list
• Numbered steps
• Source code
• Email
• Technical report
• Checklist

Weak Output Instruction

Give me the result.

Strong Output Instruction

Return the result as a Markdown table with the columns Issue, Severity, Location, Explanation, and Recommended Fix.
Sort issues from highest to lowest severity.
Do not include issues that are not supported by the provided code.

Structured Output Example

# Expected output
Return a JSON object.
Include the fields summary, issues, recommendations, and confidence.
Store issues as an array.
Each issue must contain title, severity, evidence, and fix.
Use only valid JSON.
Do not include Markdown formatting.

Output Structure for Educational Content

# Expected output
Begin with a short introduction.
Explain the concept step by step.
Include one beginner example.
Include one real-world example.
Add a comparison table where relevant.
End with a practical checklist.
Use Markdown headings and bullet points.

Output Structure for Code Review

# Expected output
Begin with an overall assessment.
List critical issues first.
Explain each issue with its code location.
Provide corrected code.
End with preventive best practices.

Handling Missing Information

A task may require information that the user has not provided. The prompt should tell the model how to respond in this situation.

Without missing-information instructions, a model may:

• Make unsupported assumptions
• Invent values
• Produce a generic answer
• Skip necessary validation
• Return a misleading result

Types of Missing Information

Missing information may involve:

• Required input data
• User goals
• Target audience
• Technical environment
• Output format
• Time period
• Business rules
• Constraints
• Definitions
• Success criteria

Missing Information Strategies

The model can be instructed to use one of the following strategies.

Ask for clarification

Use this when the missing information materially affects the result.

If the Java version is not provided, ask the user which Java version the application uses before recommending version-specific features.

Use a declared assumption

Use this when a reasonable default exists.

If no Java version is provided, assume Java 17 and clearly state the assumption.

Provide a conditional answer

Use this when several valid scenarios exist.

If the application uses Java 8, use CompletableFuture.
If it uses Java 21, also consider virtual threads.

Use placeholders

Use this for reusable templates.

Use [COMPANY NAME] when the company name is unavailable.

Return an insufficiency message

Use this when the task cannot be completed reliably.

If the SQL execution plan is missing, explain that exact performance diagnosis is not possible and list the additional information required.

Missing Information Decision Rule

Use the following decision process:

1. Determine whether the missing information changes the result.
2. Determine whether a safe default exists.
3. Determine whether the default can be stated transparently.
4. Ask for clarification when the risk of an incorrect assumption is high.
5. Never invent facts that appear to come from the user.
6. Continue with unaffected parts of the task when possible.

Missing Information Prompt Example

Review the supplied Spring Boot configuration.
If the Spring Boot version is missing, state that version-specific findings may vary.
Use Spring Boot 3.x as a working assumption.
Clearly label every recommendation that depends on this assumption.
Do not invent environment-specific values.

Handling Conflicting Requirements

Conflicting requirements occur when two or more instructions cannot be satisfied at the same time.

Examples include:

• Be extremely detailed and use no more than 100 words
• Include all technical details but avoid technical terminology
• Return only JSON and include a Markdown explanation
• Rewrite the complete code but do not change any code
• Use current information but do not access external information
• Ask questions when information is missing but do not ask any questions

Types of Conflicts

Format conflict

Return only JSON.
Explain the result in Markdown.

Length conflict

Provide a comprehensive explanation.
Limit the answer to 50 words.

Scope conflict

Analyze the entire application.
Review only the authentication module.

Behavior conflict

Do not make assumptions.
Complete the task even if information is missing.

Priority conflict

Prioritize performance.
Do not change any existing implementation decisions.

Conflict Resolution Strategy

A prompt should define how conflicts are resolved.

Recommended hierarchy:

1. Safety and legal restrictions
2. Explicit mandatory requirements
3. Primary task requirements
4. Accuracy and factual correctness
5. Output-format requirements
6. Secondary tasks
7. Style preferences
8. Optional enhancements

Conflict Resolution Prompt Example

If any instructions conflict, apply the following priority order.
First, preserve technical correctness.
Second, complete the primary task.
Third, follow the required output format.
Fourth, satisfy length and style preferences.
State any requirement that could not be satisfied.

Handling Unresolvable Conflicts

When a conflict cannot be resolved, the model should:

1. Identify the conflicting requirements.
2. Explain why both cannot be satisfied.
3. Apply the defined priority rule.
4. State which requirement was followed.
5. Avoid silently ignoring the conflict.

Example:

The request requires both valid JSON and a Markdown explanation outside the JSON object.
These requirements conflict because additional Markdown would make the response invalid JSON.
I will prioritize the valid JSON requirement and place the explanation inside a JSON field.

Preventing Conflicting Requirements

Before finalizing a prompt, check whether:

• Length limits support the requested detail
• Output formats are compatible
• Inclusion and exclusion rules overlap
• The task can be completed with the supplied data
• Mandatory instructions contradict each other
• Required behavior conflicts with prohibited behavior
• The chosen audience matches the technical depth

Task Definition Template

A task-definition template provides a reusable structure for writing precise prompts.

Basic Task Definition Template

# Intent
The purpose of this task is [DESIRED OUTCOME].
# Primary task
[STATE THE MAIN ACTION THE MODEL MUST PERFORM].
# Secondary tasks
[STATE SUPPORTING TASK 1].
[STATE SUPPORTING TASK 2].
# Expected input
The input contains [DESCRIBE INPUT TYPE AND STRUCTURE].
# Expected output
Return the result as [OUTPUT FORMAT].
# Scope
Include [REQUIRED COVERAGE].
Exclude [PROHIBITED OR IRRELEVANT COVERAGE].
# Priority
Prioritize [MOST IMPORTANT QUALITY] over [LOWER-PRIORITY QUALITY].
# Missing information
If [REQUIRED INFORMATION] is missing, [ASK FOR CLARIFICATION OR USE A DECLARED ASSUMPTION].
# Conflict handling
If requirements conflict, follow this order: [PRIORITY ORDER].
# Completion criteria
The task is complete when [MEASURABLE CONDITIONS].

Detailed Task Definition Template

# Role
Act as [RELEVANT ROLE OR EXPERTISE].
# User intent
Help the user achieve [BUSINESS, TECHNICAL, OR LEARNING OUTCOME].
# Primary task
Perform [MAIN ACTION] on [SUBJECT OR INPUT].
# Secondary task 1
Perform [SUPPORTING ACTION].
# Secondary task 2
Perform [SUPPORTING ACTION].
# Input description
The input format is [TEXT, JSON, CODE, TABLE, OR OTHER FORMAT].
# Input rules
Treat [FIELD OR SECTION] as [MEANING].
Validate [REQUIRED FIELDS OR CONDITIONS].
# Task order
First, [STEP 1].
Second, [STEP 2].
Third, [STEP 3].
# Scope boundaries
Include [IN-SCOPE ITEMS].
Exclude [OUT-OF-SCOPE ITEMS].
# Assumptions
Assume [SAFE DEFAULT] only when [CONDITION].
Label every assumption clearly.
# Output format
Return the response as [FORMAT].
Use the sections [SECTION NAMES].
# Quality requirements
Ensure the result is [ACCURATE, COMPLETE, CONCISE, OR OTHER QUALITY].
# Prohibited behavior
Do not [PROHIBITED ACTION].
# Missing information rule
If essential information is missing, [REQUIRED RESPONSE].
# Conflict resolution rule
Prioritize [REQUIREMENT 1] over [REQUIREMENT 2].
# Completion criteria
Confirm that every required input item has been processed.
Confirm that every required output section is present.
Confirm that no prohibited content is included.

Complete Practical Example

Requirement

A developer wants an AI model to review a Java service class.

Weak Prompt

Review this class and improve it.

Problems with this prompt:

• The intent is unclear
• The review scope is undefined
• The expected output is missing
• No technical environment is provided
• No completion criteria exist
• "Improve it" is subjective

Improved Prompt

# Role
Act as a senior Java and Spring Boot code reviewer.
# Intent
Help prepare the provided service class for production use.
# Primary task
Review the Java service class for correctness, security, performance, thread safety, and maintainability.
# Secondary tasks
Classify every issue as critical, high, medium, or low.
Explain the effect of every issue.
Provide corrected code for critical and high-severity issues.
# Expected input
The input contains one Java Spring Boot service class.
Assume Java 17 and Spring Boot 3 unless the code indicates otherwise.
# Task boundaries
Review only the supplied class and directly related behavior.
Do not redesign the complete application architecture.
Do not invent missing repository or database behavior.
# Expected output
Begin with an overall assessment.
Present findings in a table.
Use the columns Severity, Location, Issue, Impact, and Recommendation.
Provide corrected code after the findings.
End with a production-readiness checklist.
# Missing information
Clearly label findings that depend on unavailable application context.
Do not present assumptions as confirmed facts.
# Priority
Prioritize correctness and security over style improvements.
# Completion criteria
Review every method.
Address every critical and high-severity issue.
Ensure the corrected code is syntactically consistent.

Why the Improved Prompt Works

The improved version clearly defines:

• The reviewer's role
• The operational intent
• The primary task
• Supporting tasks
• Technical assumptions
• Scope restrictions
• Output format
• Missing-information behavior
• Task priority
• Completion conditions

The model can now produce a focused and verifiable review.

Beginner-Level Example

# Intent
Help a beginner understand Java interfaces.
# Primary task
Explain what a Java interface is.
# Required coverage
Explain interface declaration, implementation, abstract methods, default methods, and multiple inheritance of type.
# Audience
Assume the reader understands basic Java classes and methods.
# Expected output
Use simple language.
Include one code example.
End with three key points.
# Boundary
Do not discuss advanced framework usage.

Intermediate-Level Example

# Intent
Prepare an intermediate Java developer for interviews.
# Primary task
Compare interfaces and abstract classes in Java.
# Secondary tasks
Explain design trade-offs.
Include practical use cases.
Include common interview questions.
# Expected output
Use a comparison table.
Include one example using an interface.
Include one example using an abstract class.
End with a decision checklist.
# Completion criteria
Cover inheritance, constructors, fields, methods, access modifiers, and multiple inheritance.

Advanced-Level Example

# Intent
Support an architectural decision for a modular Java application.
# Primary task
Evaluate whether interfaces, abstract classes, or composition should be used for the payment-processing module.
# Expected input
The module supports multiple payment providers with provider-specific validation and shared audit behavior.
# Secondary tasks
Compare extensibility, testability, coupling, and runtime flexibility.
Recommend one design.
Explain trade-offs.
# Boundaries
Do not generate a complete application.
Do not assume a specific payment vendor.
# Priority
Prioritize maintainability and provider extensibility.
# Completion criteria
Provide a recommendation supported by technical reasoning and one simplified class-design example.

Business Use Case

Consider a business that receives hundreds of customer reviews. The business wants an AI model to identify common complaints and recommend improvements.

Poor Task Definition

Analyze these reviews.

Strong Task Definition

# Intent
Help the product team identify customer-experience problems.
# Primary task
Analyze the supplied customer reviews and identify recurring complaint themes.
# Secondary tasks
Measure the frequency of each theme.
Classify sentiment as positive, neutral, or negative.
Identify the three issues with the highest customer impact.
Recommend one action for each high-impact issue.
# Expected input
The input is a list of customer reviews containing reviewId, rating, date, and comment.
# Task boundaries
Base conclusions only on the supplied reviews.
Do not infer customer demographics.
Do not claim statistical significance unless the data supports it.
# Expected output
Begin with an executive summary.
Present themes in a table.
Include review count, sentiment, evidence, impact, and recommendation.
# Completion criteria
Process every review.
Include evidence for every major finding.
Clearly identify limitations in the dataset.

This prompt connects the analysis task with the business decision it is intended to support.

Technical Use Case

Suppose a developer needs help diagnosing a slow SQL query.

Strong Technical Prompt

# Intent
Identify the cause of slow database query execution.
# Primary task
Analyze the supplied PostgreSQL query and execution plan.
# Secondary tasks
Identify expensive operations.
Identify missing or ineffective indexes.
Detect unnecessary scans, joins, sorts, and filters.
Recommend query and indexing improvements.
# Expected input
The input contains the SQL query, EXPLAIN ANALYZE output, table sizes, and existing indexes.
# Boundaries
Do not recommend removing data-integrity constraints.
Do not assume hardware limitations without evidence.
# Expected output
Begin with the most likely bottleneck.
Explain each execution-plan issue.
Rank recommendations by expected impact.
Include revised SQL where appropriate.
# Missing information
If table statistics or index definitions are missing, state how that limits the diagnosis.
# Completion criteria
Account for the highest-cost execution-plan nodes.
Explain how every recommendation addresses an observed problem.

Task Decomposition for Complex Prompts

Complex tasks should be divided into logical stages.

A useful decomposition model is:

1. Validate
2. Understand
3. Analyze
4. Transform
5. Verify
6. Present

Decomposition Example

# Step 1
Validate that every input record contains id, name, email, and status.
# Step 2
Separate valid and invalid records.
# Step 3
Normalize valid names and email addresses.
# Step 4
Identify duplicate email addresses.
# Step 5
Produce the final cleaned dataset.
# Step 6
Return a validation summary.

Each stage has a clear purpose and dependency.

Common Task Definition Mistakes

Using Vague Action Words

Weak:

Improve this content.

Better:

Rewrite this content to improve clarity, remove repetition, and make it suitable for beginner Java developers.

Combining Unrelated Tasks

Weak:

Explain microservices, create a logo, review my resume, and generate SQL interview questions.

These tasks should be separated because they do not share a common objective or input.

Omitting the Intended Audience

Weak:

Explain Kubernetes.

Better:

Explain Kubernetes to a backend developer who understands Docker but has not used container orchestration.

Missing Output Requirements

Weak:

Analyze this data.

Better:

Analyze this sales data and return a Markdown table containing monthly revenue, growth rate, highest-performing product, and key observations.

Undefined Scope

Weak:

Review my application.

Better:

Review the authentication flow shown in the supplied controller, service, and security configuration.

No Missing-Information Rule

Weak:

Recommend the best cloud architecture.

Better:

Recommend a cloud architecture based on the supplied traffic, availability, compliance, and budget requirements.
If a critical requirement is missing, list the missing information before presenting conditional options.

Contradictory Requirements

Weak:

Explain every detail in fewer than 50 words.

Better:

Provide a 50-word summary followed by a detailed explanation of no more than 800 words.

Unmeasurable Completion

Weak:

Make the answer good.

Better:

Include a definition, working process, practical example, comparison table, common mistakes, and final checklist.

Best Practices for Defining Tasks and Intent

• Begin with the user's desired outcome.
• Use a specific action verb.
• Define one primary task.
• Separate supporting tasks.
• Number tasks when order matters.
• Specify what input will be supplied.
• Describe how the input should be interpreted.
• Set clear scope boundaries.
• Define the expected output format.
• Establish measurable completion criteria.
• State what the model should do when information is missing.
• Provide conflict-resolution rules.
• Distinguish mandatory and optional requirements.
• Avoid combining unrelated objectives.
• Use examples only when they clarify expected behavior.
• Validate that all requirements can be satisfied together.

Task Quality Checklist

Before using a prompt, verify the following points.

Intent

• Is the user's desired outcome clear?
• Is the intended use of the response known?
• Is the target audience identified?

Primary Task

• Is there one clearly defined primary task?
• Does the task use a specific action verb?
• Is the task possible with the available input?

Secondary Tasks

• Are supporting tasks clearly separated?
• Are optional tasks identified as optional?
• Do secondary tasks support the primary objective?

Priority

• Is the most important requirement identified?
• Is task order specified where necessary?
• Is there a rule for resolving conflicts?

Boundaries

• Is the permitted scope clear?
• Are exclusions explicitly stated?
• Are assumptions controlled?
• Is the stopping point defined?

Input

• Is the input type defined?
• Are required fields specified?
• Are delimiters used where necessary?
• Is invalid-input behavior defined?

Output

• Is the output format specified?
• Are required sections or fields listed?
• Is the desired level of detail clear?
• Are length and style requirements compatible?

Missing Information

• Does the prompt define when to ask questions?
• Are safe assumptions identified?
• Must assumptions be clearly labelled?
• Is invented information prohibited?

Completion

• Can the result be objectively evaluated?
• Must every input item be processed?
• Are all required sections measurable?
• Is a final validation step required?

Final Task Definition Example

# Role
Act as an experienced prompt engineer and technical educator.
# User intent
Help beginner developers learn how to write effective prompts for code generation.
# Primary task
Create a practical tutorial explaining how to define coding tasks clearly.
# Secondary tasks
Explain how to specify programming language, framework, inputs, outputs, constraints, and error handling.
Include weak and improved prompt examples.
Include one Java example and one Python example.
# Expected input
No external input is required.
# Expected output
Write the response in Markdown.
Begin with an introduction.
Explain each concept point by point.
Include comparison tables where useful.
End with a task-definition checklist.
# Scope
Focus on code-generation prompts.
Do not cover image, audio, or video generation.
# Audience
Write for beginner developers with basic programming knowledge.
# Priority
Prioritize technical clarity and practical usefulness over brevity.
# Missing information
Use common Java and Python development scenarios when examples are needed.
Clearly identify examples as illustrative.
# Conflict handling
If brevity conflicts with completeness, prioritize completeness.
If style conflicts with technical correctness, prioritize technical correctness.
# Completion criteria
Cover task definition, expected input, expected output, constraints, edge cases, error handling, and validation.
Include at least two complete prompt examples.
Ensure every instruction is directly actionable.

Conclusion

Defining the task and intent is one of the most important principles in prompt engineering. A model cannot reliably produce the desired result when the prompt does not clearly state what must be done, why it matters, what information should be processed, and how success will be measured.

A strong prompt begins with a clear user intent and converts that intent into one primary task. It then adds supporting tasks, priorities, boundaries, input rules, output requirements, missing-information behavior, conflict-resolution logic, and measurable completion criteria.

The most effective task definitions answer the following questions:

• What outcome does the user want?
• What is the model's primary action?
• Which supporting actions are required?
• What input should be processed?
• What output should be produced?
• What is included and excluded?
• Which requirements have the highest priority?
• What should happen when information is missing?
• How should conflicts be resolved?
• How will successful completion be verified?

When these questions are answered clearly, prompts become more predictable, testable, reusable, and effective across educational, technical, business, analytical, and software-development tasks.

Frequently Asked Questions