How to Write Clear AI Instructions

How to Write Clear AI Instructions

An AI instruction tells the model what you want it to do.

Clear instructions help the model understand the task, use the right information, and return the result in a format you can review.

You can use the same principles in:

• Workbench conversations;
• AI steps inside Studio;
• prompts included with Genes; and
• repeatable workflows.

A useful instruction does not need to be long. It needs to be specific enough for the model to understand the task.

Start with the outcome

Before writing the instruction, decide what you want to receive.

Ask yourself:

• What task should the model complete?
• What information should it use?
• What should the answer include?
• What format should the answer use?
• What should the model avoid?

When the outcome is unclear to you, it will also be unclear to the model.

Instead of:

Help me with these notes.

Try:

Summarise these notes in five bullet points.

Include the decisions, action items, owners, and deadlines.
List unanswered questions at the end.

The second instruction gives the model a clear task and a clear result.

Use a simple instruction structure

A strong instruction often contains five parts.

Part	What it explains
Task	What the model should do
Source	What information the model should use
Requirements	What the answer must include
Format	How the answer should be organised
Limits	What the model should not do

You do not need all five parts for every request. Use the parts that make the expected result clearer.

1. State the task

Begin with a direct action.

Useful action words include:

• summarise;
• classify;
• compare;
• extract;
• rewrite;
• organise;
• explain;
• review;
• translate; and
• draft.

Instead of:

What do you think about this?

Try:

Review the customer message and identify the main issue.

The revised instruction tells the model exactly what action to perform.

2. Provide the source information

Tell the model what information it should use.

Place the source after the instruction and label it clearly.

For example:

Summarise the meeting notes below.

Meeting notes:
[Paste the notes here.]

When several types of information are included, separate them with clear labels.

For example:

Compare the customer request with the company policy.

Customer request:
[Paste the request here.]

Company policy:
[Paste the policy here.]

Clear labels help prevent the model from confusing the instruction with the source material.

3. Explain what the answer must include

List the details that matter.

For example:

Review the project update.

Include:
1. completed work;
2. current blockers;
3. upcoming deadlines; and
4. decisions that still need to be made.

This is more reliable than asking for a general review and hoping the model chooses the same details you need.

Keep the list focused. Too many requirements in one request can make the answer difficult to follow.

4. Choose an output format

Tell the model how to present the result.

Common formats include:

• bullet points;
• numbered steps;
• a table;
• a short paragraph;
• headings and sections;
• a checklist;
• a draft message; or
• structured fields.

For example:

Return the result as a table with these columns:

* Owner
* Action
* Deadline
* Status

A clear format makes the response easier to review and reuse.

5. Add useful limits

Limits tell the model what not to do or where to stop.

Useful limits may include:

• a maximum length;
• a required language;
• a reading level;
• a tone;
• source boundaries;
• information that must not be added; or
• topics that should be excluded.

For example:

Use plain language.
Keep the summary under 150 words.
Do not add information that is not present in the source.

Add limits only when they help the task. Too many rules can make the instruction harder to follow.

A complete instruction example

Here is a complete instruction for reviewing meeting notes:

Read the meeting notes below.

Create:
1. a summary of no more than 100 words;
2. a list of decisions;
3. a table of action items with Owner, Task, and Deadline; and
4. a list of unanswered questions.

Use only information from the notes.
Write in clear, professional English.
If an owner or deadline is missing, write "Not provided."

Meeting notes:
[Paste the notes here.]

This instruction explains the task, source, required content, format, and limits.

Give the model enough context

Context explains why the task matters or who the result is for.

Add context when it affects the answer.

For example:

You are preparing a handover for a colleague who was not in the meeting.

Summarise the notes in plain language and explain any decisions that
affect next week's work.

The audience changes what the model should explain and how much background it should include.

Useful context may include:

• who will read the answer;
• what the answer will be used for;
• the reader's level of knowledge;
• the preferred tone; and
• the situation surrounding the task.

Do not include background that does not affect the result.

Be specific about tone

Tone describes how the answer should sound.

Examples include:

• clear;
• friendly;
• professional;
• neutral;
• reassuring;
• concise; or
• formal.

Instead of:

Make this better.

Try:

Rewrite this message in a friendly, professional tone.

Keep the meaning unchanged and use no more than 120 words.

Avoid vague style requests such as "make it amazing" or "make it sound smart." Describe the effect you want for the reader.

Ask for plain language

AI responses can become more complicated than necessary.

When the result is intended for a general audience, say so directly.

For example:

Explain this in plain language for a reader with no technical
background.

Use short paragraphs and define any specialist term that cannot be
avoided.

This is useful for customer messages, documentation, summaries, and internal explanations.

Tell the model how to handle missing information

A model may try to complete gaps when information is missing.

Prevent this by explaining what it should do.

For example:

If the source does not provide an answer, write "Not provided."
Do not guess or create missing details.

You can also ask the model to list missing information separately.

For example:

After the summary, list any information needed before the request can be
completed.

This makes gaps visible instead of hiding them inside a confident answer.

Separate facts from suggestions

When a task includes both source-based facts and model suggestions, ask the model to separate them.

For example:

Create two sections:

1. Facts stated in the source
2. Suggested next steps

Do not present suggestions as confirmed facts.

This makes the result easier to review and reduces confusion.

Use examples when the format is unusual

A short example can help when you need a specific style or structure.

For example:

Classify each message using one of these labels:

* Question
* Complaint
* Request
* Other

Example:
Message: "My order arrived damaged."
Label: Complaint

Now classify the messages below:
[Paste messages here.]

Use examples that closely match the real task.

Do not provide so many examples that the actual instruction becomes hard to find.

Divide large tasks into stages

A large request may be more reliable when it is divided into smaller steps.

Instead of asking the model to read a long document, analyse it, create a report, write an email, and prepare a task list in one message, work in stages.

For example:

1. Ask for the main facts.
2. Review the facts.
3. Ask for risks or missing information.
4. Review the analysis.
5. Ask for the final report.

In Workbench, you can complete these stages through follow-up messages.

In Studio, each stage can become a separate workflow step when the process needs to be repeated.

Use follow-up instructions

You do not need to rewrite the entire instruction when only one part needs improvement.

Useful follow-ups include:

Shorten the summary to 80 words.

Turn the action items into a table.

Rewrite the answer for a non-technical reader.

Remove any suggestion that is not supported by the source.

Explain which information is missing.

Keep follow-ups focused on one clear change.

Start a new conversation when you move to a different task or source.

Avoid vague instructions

Vague instructions leave important choices to the model.

Vague instruction	Clearer instruction
"Improve this."	"Rewrite this email in a friendly, professional tone and keep it under 150 words."
"Analyse this."	"Identify the main issue, urgency, missing details, and recommended next step."
"Make a report."	"Create a report with Summary, Findings, Risks, and Next Actions."
"Make it shorter."	"Reduce this to five bullet points without removing dates or action items."
"Tell me everything."	"List the five most important points for a new team member."

Clear instructions reduce the number of corrections needed later.

Avoid conflicting instructions

A model may struggle when the instruction asks for opposing results.

For example:

Explain everything in detail, but keep the answer extremely short.

Decide which requirement matters more.

A clearer version would be:

Give a short overview first, followed by a detailed explanation under
separate headings.

Review the instruction for rules that compete with each other.

Avoid unnecessary roles

Sometimes it helps to explain the model's role, especially when the task needs a particular viewpoint.

For example:

Act as an editor reviewing this article for clarity and repetition.

A role is less useful when it only adds decoration.

For example:

You are the greatest expert in the world.

Focus on the task, audience, and review criteria instead of exaggerated titles.

Keep instructions reusable

When an instruction works well, separate the fixed directions from the information that changes.

For example:

Task:
Summarise the source in five bullet points.

Requirements:
Include decisions, owners, deadlines, and open questions.
Do not add information that is not in the source.

Source:
[Insert new source here.]

This structure is easier to reuse in Workbench and easier to turn into a workflow later.

Test the instruction

A useful instruction should work with more than one example.

Test it with:

• a normal example;
• a short example;
• an example with missing information;
• an example with extra information; and
• an example that does not fit the expected pattern.

Review whether the model follows the same rules each time.

Improve the instruction when the model:

• misses important details;
• adds unsupported information;
• uses the wrong format;
• becomes too long;
• handles missing data poorly; or
• misunderstands the source.

Compare models fairly

Different AI models may respond differently to the same instruction.

When comparing models:

1. use the same instruction;
2. use the same source information;
3. start a new conversation for each model;
4. apply the same review criteria; and
5. compare both accuracy and clarity.

Do not change the instruction between models unless you are testing how each model responds to a revised version.

Protect private information

Do not include API keys, passwords, access tokens, or other private credentials in an instruction.

Before using confidential information:

• confirm which provider and model are selected;
• check whether the model is local or cloud-based;
• remove details that are not needed;
• review enabled tools; and
• understand whether an outside service will receive the information.

Use sample content while developing and testing a new instruction.

Review the result

A clear instruction improves the response, but it does not guarantee that every answer is correct.

Check whether the model:

• completed the requested task;
• used the correct source;
• followed the required format;
• respected the limits;
• handled missing information correctly; and
• added any unsupported claims.

Important work should always be reviewed by a person before it is used.

Turn a good instruction into a workflow

When an instruction produces a useful result consistently, it may be ready for Studio.

A simple path is:

1. test the instruction in Workbench;
2. improve it through follow-up messages;
3. test it with several examples;
4. define which information changes each time;
5. add the instruction to an AI step in Studio; and
6. test the workflow before regular use.

This turns a successful one-time conversation into a repeatable process.

A practical instruction template

Use this template as a starting point:

Task:
[State what the model should do.]

Context:
[Explain the audience or purpose when relevant.]

Requirements:
* [Required detail 1]
* [Required detail 2]
* [Required detail 3]

Output format:
[Describe the structure of the answer.]

Limits:
[State length, tone, source boundaries, or other rules.]

Source:
[Add the information the model should use.]

Remove any section that does not help the task.

Start with clarity, then improve

Your first instruction does not need to be perfect.

Begin with a clear task, useful source information, and a reviewable output format.

Test the result, identify what is missing, and improve one part at a time.

Once the instruction works reliably, save it for reuse or turn it into a workflow in Studio.