How to Write Effective AI Prompts

How to Write Effective AI Prompts

Effective AI prompts give a model a clear task, the right context, and a usable definition of success.

A good prompt does not need to sound technical.

It needs to reduce unnecessary guessing.

The most useful prompts explain:

• what the model should do;
• why the task is being performed;
• which information it should use;
• what the result must contain;
• which format it should follow;
• what it must not invent or change; and
• how it should handle missing or uncertain information.

This becomes especially important when prompts are reused in AI workflows.

During a conversation, a user can correct the model through follow-up messages.

A workflow prompt must often work with new input without someone rewriting the instruction each time.

The goal is not to create the longest possible prompt.

The goal is to create the clearest prompt that reliably produces the required result.

Begin with the intended outcome

Before writing the prompt, define what a successful result should accomplish.

Avoid broad goals such as:

Help me with customer support.

Use a specific outcome:

Classify each customer message into one approved support category and
identify whether human review is required.

A useful outcome answers:

• What should the model produce?
• Who will use the result?
• What will happen after the response?
• Which details are essential?
• Which errors would make the result unusable?
• How will the result be checked?

The outcome determines the structure of the prompt.

A summary prompt needs different instructions from an extraction prompt.

A prompt used for drafting requires different safeguards from a prompt used to trigger a tool.

Give the model one primary task

Prompts become less reliable when they combine many unrelated responsibilities.

Consider this request:

Read the message, identify the customer, research the account, determine
whether the complaint is valid, write a reply, update the record, and
create a management report.

This is not one task.

It is a complete process.

A stronger design separates it into stages:

Customer Message
→ Classify the Issue
→ Extract Stated Details
→ Retrieve Approved Account Information
→ Draft a Reply
→ Human Review
→ Update the Record

Each AI step can then use a focused prompt.

Focused prompts are easier to:

• understand;
• test;
• evaluate;
• debug;
• reuse;
• replace; and
• maintain.

When a prompt must contain several related actions, state their order explicitly.

Use a direct action verb

Start with a verb that describes the model's responsibility.

Useful verbs include:

• classify;
• extract;
• summarise;
• compare;
• rewrite;
• organise;
• identify;
• translate;
• review;
• draft;
• rank; and
• verify.

Avoid vague instructions such as:

Improve this.

A clearer version is:

Rewrite the report for senior management.

Preserve all facts, dates, amounts, and named owners.
Remove repetition.
Use no more than 500 words.
End with a list of unresolved decisions.

The revised prompt defines what improvement means.

Add relevant context

Context explains the situation surrounding the task.

Useful context may include:

• the intended audience;
• the purpose of the output;
• the reader's level of knowledge;
• the workflow stage;
• the communication channel;
• the product or service involved;
• the applicable policy; and
• the decision that follows.

Example:

The reader is a project manager who has not read the full technical
report.

Create a summary that explains progress, blockers, decisions, owners,
and deadlines.

This changes which information the model should prioritise.

Context should be relevant.

Too much background can distract the model and make the prompt harder to maintain.

Include information only when it changes the expected result.

Separate instructions from source material

The model should be able to distinguish between:

• the instruction it must follow; and
• the content it must analyse.

Use headings, tags, or delimiters.

Example:

Task:
Extract the required fields from the customer message.

Required fields:
* Customer name
* Order number
* Main issue
* Requested action
* Deadline

Rules:
* Use only the customer message.
* Do not infer missing values.
* Return "Not provided" when a field is absent.

Customer message:
<source>
[Insert customer message]
</source>

This structure is useful when the source contains:

• quoted instructions;
• email chains;
• website content;
• user-generated text;
• code;
• support messages;
• retrieved documents; or
• tool output.

Source content should normally be treated as information, not as authority to change the task.

Define what the output must contain

Do not make the model guess which details matter.

List the required elements.

Example:

Summarise the meeting notes.

Include:
* decisions;
* action items;
* owners;
* deadlines;
* blockers; and
* unanswered questions.

Required elements improve consistency and make review easier.

If the result omits a deadline or owner, the failure is visible.

Without a required-content list, two polished answers may cover completely different information.

Choose the right output format

The format should match how the result will be used.

Use paragraphs when the output is intended for natural reading.

Use bullet points when the reader needs fast scanning.

Use tables when several items must be compared using the same criteria.

Use fixed headings when repeated outputs should remain consistent.

Use labels or structured fields when another workflow step will inspect the result.

Use JSON when software needs predictable keys and values.

Example:

Return the result using these headings:

Issue:
Customer request:
Important facts:
Missing information:
Recommended next step:
Human review required:

For software-oriented output:

Return [valid JSON](/prompt-engineering/how-to-prompt-ai-for-structured-output) using this structure:

{
  "issue": "",
  "requested_action": "",
  "missing_information": [],
  "review_required": false
}

Do not add additional keys.

Structured output still needs validation.

Correct syntax does not prove that the values are accurate.

Define allowed values

Classification prompts are more reliable when the model must choose from a known set of labels.

Example:

Choose exactly one category:

Billing
Technical Issue
Cancellation
Product Question
Other
Human Review

Define each label.

For example:

Billing:
Questions or complaints about invoices, payments, charges, refunds, or
payment methods.

Technical Issue:
Problems using the product, application, account, or connected feature.

Cancellation:
Requests to stop, close, or end a service or subscription.

Label definitions should be:

• distinct;
• complete enough for normal input;
• consistent with the real process; and
• supported by an uncertain or review route.

Do not force the model to select a confident category when the input is genuinely unclear.

Explain how to handle missing information

Models often attempt to complete incomplete input.

This can create invented names, dates, amounts, owners, deadlines, or explanations.

Add an explicit missing-information rule.

Example:

If the source does not contain a required value, return
"Not provided."

Do not infer or calculate a value unless the instruction specifically
requires a calculation.

Other useful statuses include:

• Unclear;
• No matching evidence;
• Conflicting information;
• Needs clarification; and
• Human review required.

Missing information should become visible rather than silently filled.

Define what the model must not change

Rewriting tasks can accidentally alter facts.

A prompt should distinguish between language changes and factual changes.

Example:

Rewrite the announcement in a clear and professional tone.

Preserve:
* all names;
* all dates;
* all prices;
* all product names;
* all conditions; and
* the original meaning.

Do not add [promises, benefits, deadlines](/gaas/benefits-of-agentic-as-a-service), or features that are not
present in the source.

This is more reliable than:

Make this sound better.

Use measurable constraints

Replace subjective instructions with limits that can be checked.

Instead of:

Keep it short.

Use:

Use no more than 150 words.

Instead of:

Make it easy to read.

Use:

Use short paragraphs, plain language, and no more than five bullet
points.

Instead of:

Write a detailed answer.

Use:

Include a definition, three examples, two limitations, and one practical
checklist.

Useful measurable constraints include:

• maximum word count;
• number of sections;
• number of examples;
• allowed labels;
• required fields;
• sentence length;
• reading level;
• number of recommendations; and
• permitted source material.

Avoid contradictory requirements

Review the prompt for rules that cannot all be satisfied.

Common contradictions include:

• highly detailed but under 50 words;
• creative but unable to add anything;
• exhaustive but limited to three bullet points;
• persuasive but completely neutral;
• one category but multiple categories allowed;
• use only the source but include external recommendations; and
• explain fully but provide no explanation.

When two requirements compete, decide which one has priority.

State that priority clearly.

Example:

Accuracy is more important than brevity.

If the required facts cannot fit within 150 words, use up to 220 words.

Use examples when instructions are not enough

Examples can clarify:

• tone;
• structure;
• category boundaries;
• field formatting;
• acceptable length;
• uncertainty handling; and
• the difference between correct and incorrect output.

A one-shot prompt provides one example.

A few-shot prompt provides several.

Example:

Classify the message as Billing, Technical Issue, Cancellation, or
Other.

Example 1:
Message: "Why was I charged twice?"
Category: Billing

Example 2:
Message: "The application closes when I upload a file."
Category: Technical Issue

Example 3:
Message: "Please close my account at the end of the month."
Category: Cancellation

Examples should reflect normal and difficult cases.

Do not use only simple examples that make category boundaries appear clearer than they are.

Include negative examples carefully

A negative example shows what the model should avoid.

Example:

Incorrect:
"The customer probably wants a refund."

Reason:
The source does not mention a refund.

Correct:
"Requested action: Not provided."

Negative examples are useful when the model repeatedly makes the same type of assumption.

Keep them concise.

Too many examples can consume context and distract from the current task.

Prompt for evidence, not confidence

A confident answer is not necessarily an accurate answer.

Ask the model to identify the evidence supporting important conclusions.

Example:

For each identified risk, include:

* Risk
* Supporting source text
* Potential impact
* Missing information
* Review required

This makes unsupported conclusions easier to detect.

Evidence requests are especially useful for:

• policy review;
• document comparison;
• contract analysis;
• research;
• project risks;
• compliance preparation; and
• knowledge-base answers.

A quoted passage is still not proof that the model interpreted it correctly.

Important conclusions require source review.

Control tone with observable guidance

Tone instructions become more reliable when they describe specific language choices.

Instead of:

Use a professional tone.

Use:

Use direct, respectful language.
Avoid slang, exaggerated claims, humour, and unnecessary enthusiasm.
Use short paragraphs.
Address the reader as "you."

Instead of:

Make it friendly.

Use:

Use a warm opening, plain language, and helpful wording.
Do not use excessive exclamation marks or informal abbreviations.

Include a short example when the required voice is difficult to describe.

Prompting for tool use

When a model can use tools, the prompt should clarify:

• the objective;
• which information may be sent;
• when the tool is needed;
• which actions require approval;
• what to do after a tool error;
• when to stop; and
• how to report the result.

Example:

Use the approved knowledge-search tool only when the answer is not
contained in the user's message.

Search only for information relevant to the question.
Do not use any write tool.
Cite the returned source in the answer.
If no suitable source is found, state that the information could not be
verified.

Prompt instructions should not replace tool permissions or deterministic access controls.

Keep prompts readable

A prompt should be easy for another person to review.

Use clear sections such as:

Role
Task
Context
Source
Requirements
Output
Constraints
Uncertainty handling

Avoid unnecessary decorative language.

Avoid repeating the same rule several times unless testing shows that the repetition improves performance.

A readable prompt is easier to maintain and less likely to contain hidden contradictions.

Test the prompt with representative inputs

A prompt should be tested with more than one ideal example.

Include:

• normal input;
• short input;
• long input;
• missing information;
• conflicting information;
• unusual wording;
• poor formatting;
• irrelevant content;
• another language where applicable;
• instructions embedded in source material;
• out-of-scope requests; and
• cases requiring human review.

Define the expected result for each case before reviewing the model output.

Evaluate more than writing quality

A polished response can still fail the task.

Measure:

• factual accuracy;
• source faithfulness;
• required-section coverage;
• classification accuracy;
• field accuracy;
• format compliance;
• missing-information handling;
• unsupported claims;
• tool use;
• latency;
• cost;
• correction time; and
• reviewer acceptance.

The best prompt is the one that produces the required outcome consistently, not the one that sounds most sophisticated.

Revise one element at a time

When improving a prompt, change one main element before testing again.

For example:

1. clarify the task;
2. improve the label definitions;
3. add missing-value handling;
4. change the output format;
5. add examples; and
6. reduce irrelevant context.

Changing everything at once makes it difficult to understand why the result improved or became worse.

Compare prompt versions fairly

Use the same:

• model;
• model version;
• source material;
• test cases;
• tools;
• settings;
• validation; and
• scoring criteria.

Record the prompt version and results.

A prompt that performs better with one model may perform worse with another.

Retest after changing the model.

Avoid overengineering prompts

Longer prompts are not automatically better.

Excessive instructions can:

• create contradictions;
• hide the primary task;
• consume context;
• increase maintenance effort;
• reduce flexibility; and
• make failures harder to diagnose.

Begin with the smallest prompt that clearly defines the task.

Add examples, constraints, or explanations only when evaluation shows that they are needed.

Use deterministic logic for exact requirements

Do not ask a model to make a variable decision when a fixed rule can provide the answer reliably.

Use deterministic logic for:

• calculations;
• thresholds;
• required-field checks;
• date validation;
• identifier formats;
• duplicate detection;
• permissions;
• approved destinations; and
• routing based on known values.

AI is useful for interpretation.

Normal workflow logic is better for exact control.

Writing prompts for Feluda Workbench

Workbench is useful for developing a prompt interactively.

A practical process is:

1. select the intended model;
2. send a simple version of the instruction;
3. review the response;
4. identify omissions or unsupported claims;
5. add clearer requirements;
6. test another example;
7. compare local and cloud models where relevant; and
8. inspect tool activity when tools are enabled.

Keep the conversation focused during testing.

Start a new conversation when earlier messages could influence the result.

Writing prompts for Feluda Studio

Studio prompts should be designed for repeated execution.

Define:

• expected input;
• one clear task;
• required output;
• missing-value behaviour;
• validation needs;
• error handling; and
• the next workflow step.

A workflow might look like:

Customer Message
→ LLM Label: Classify Request
→ LLM Extract: Extract Stated Details
→ Expression: Validate Required Fields
→ LLM: Draft Reply
→ Output: Review Draft

Each prompt serves one part of the process.

This is easier to test than one large instruction that performs every step.

Match the prompt to the selected model

Different models may respond differently to the same prompt.

A smaller local model may benefit from:

• shorter instructions;
• fewer simultaneous requirements;
• explicit labels;
• fixed output formats;
• clear examples; and
• narrow source material.

A larger model may handle more complex instructions but can still ignore constraints or invent details.

Test the prompt with the exact model that will be used in Workbench or Studio.

Review the full workflow result

A prompt can produce a correct intermediate result while the complete workflow still fails.

Review:

• the input passed to the prompt;
• the model selected;
• the output returned;
• validation results;
• branch selection;
• tool calls;
• tool results;
• errors;
• retries; and
• final output.

RunFlows can help expose how saved Feluda workflows behave with new input.

Test every important path before relying on the workflow regularly.

Maintain prompts over time

Record:

• prompt name;
• version;
• purpose;
• model;
• model version;
• tools;
• input format;
• expected output;
• test set;
• evaluation results;
• known limitations; and
• change history.

Retest after changes to:

• the model;
• provider;
• prompt;
• source format;
• retrieval system;
• available tools;
• output schema;
• workflow;
• language; or
• user group.

Keep the previous dependable version available when possible.

Effective prompt template

The following structure can be adapted to many tasks:

Role:
[Optional description of the perspective or responsibility]

Task:
[One clear action]

Context:
[Relevant purpose, audience, and background]

Source:
<source>
[Insert source material]
</source>

Requirements:
* [Required item]
* [Required item]
* [Required item]

Output format:
[Headings, fields, table, labels, or schema]

Constraints:
* Use only the supplied source.
* Do not invent missing details.
* [Additional task-specific limits]

Missing information:
Return "Not provided" when a required detail is absent.

Review condition:
Return "Human review required" when the request cannot be completed
confidently from the available source.

Remove sections that do not add value to the specific task.

Prompt review checklist

Before using a prompt regularly, confirm that:

• the outcome is clear;
• the prompt has one primary task;
• the action verb is specific;
• relevant context is included;
• source material is clearly separated;
• required content is listed;
• the output format matches its next use;
• allowed values are defined;
• missing information is handled;
• factual details are protected during rewriting;
• constraints are measurable;
• instructions do not contradict each other;
• examples are representative;
• evidence is requested when needed;
• clarification or review routes are available;
• normal and difficult inputs are tested;
• exact requirements are validated outside the model;
• the exact model is tested;
• the prompt version is recorded; and
• a fallback exists when the prompt cannot produce a reliable result.