Clear and Specific Instructions

The colleague test

Anthropic's prompting guide gives a simple test: "Show your prompt to a colleague with minimal context on the task and ask them to follow it. If they'd be confused, Claude will be too." The same holds for any model. The difference is that a colleague would ask what you mean; a model usually picks one interpretation and answers it with full confidence.

An ambiguous prompt is a prompt that a reasonable reader could understand in more than one way, so that the model, not you, decides what is being asked. Ambiguity hides in ordinary words:

• "Summarize this ticket" — for whom? The customer, the next shift and the problem manager need different summaries.
• "Check this config" — for syntax errors, security problems, or whether it matches the change request?
• "Use the latest version" — the latest the model knows of from training, which may be a year old, or the one you run?
• "Make it shorter" — by a sentence, or to half?

Each of these is clear to the writer, who knows the situation. The fix is to write down what you know and the model does not.

Name the audience, purpose and scope

Microsoft's prompt engineering guide puts it briefly: "Be specific. Leave as little to interpretation as possible. Restrict the operational space." In practice that means three things most prompts leave out: who will read the answer, what it is for, and what it should and should not cover. Microsoft's Copilot guidance calls this part of a prompt the "expectations", such as the tone the answer should have.

Explain what a DNS TTL is.

Kestrel Energy moved its customer portal to a new address yesterday. Some customers still reach the old address. Explain to service desk staff, who know what DNS is but not what a TTL is, why this can happen for up to an hour after the move. Four sentences, no commands. End with one sentence they can say to a customer who calls about it.

The vague prompt gets a general textbook answer that may be perfectly correct and still useless at the service desk. The specific one names the reader and what they already know, the situation, the length, an exclusion (no commands) and the practical end point. For explaining technical things to non-specialists in general, see Plain language.

Being specific also covers ambition. Anthropic's guide notes that if you want "above and beyond" behavior, you should explicitly request it rather than rely on the model to infer it from a vague prompt. "Write a runbook for restarting the meter-data importer" gets the steps; if you also want checks before and after, a back-out plan and the expected log lines, ask for them.

Say whether you want advice or action

"Can you suggest some changes to this script?" and "Change this script so that it…" ask for different things, and models react to that difference. Anthropic's guide notes that with the first phrasing Claude may only suggest, while the second makes it act. OpenAI's guide for GPT-6 Astra says the model is more likely than earlier ones to ask for clarification, and offers a sample prompt ("bias towards action and carry the user's intended task to completion") for when you want it to act on its own. The defaults differ between vendors and model versions, so do not leave it to the default:

Can you look at this firewall rule?
permit tcp any host 198.51.100.20 eq 22

Explain in three bullets what this firewall rule allows and what risk it carries. Give advice only; I will decide on any change myself.
permit tcp any host 198.51.100.20 eq 22

This matters most when the assistant can change things: a coding assistant that edits files, or an agent with access to tools. "Have a look at" is not a safe instruction for a system that can act. More on this on Prompting for Code and Context Engineering and Agents.

Give length in numbers

A length limit is an explicit, countable bound on the size of an answer, such as "at most three sentences", "five bullets" or "under 80 words". Words like "short", "brief" and "concise" mean different things to different readers, and to a model they mean roughly "typical for this kind of text", which is often longer than you want.

• Sentences, bullets and lines are easiest to follow. They are units the model can see in its own output. Word limits are usually kept only approximately, because the model works in tokens, not words.
• A template shows the length as well as the structure: three labeled lines are three lines.
• Settings do not replace the instruction. Anthropic notes that on one model, Claude Opus 5, raising or lowering the effort setting does not reliably change how long the visible answer is, and advises asking for conciseness explicitly in the prompt instead (as of October 2026). The general lesson holds for any model: ask for the length you want.

Vague words are easy to miss in your own prompt. The small checker below flags a few of them and suggests what to write instead. It is a word list, not a judge of good writing, but it catches the usual suspects:

import re

# Words that leave the model to guess, with what to write instead.
VAGUE = {
    "short": "a number: 'at most 3 sentences'",
    "brief": "a number: 'under 60 words'",
    "a few": "an exact count: 'three'",
    "asap": "a time: 'before 14:00 today'",
    "recent": "a period: 'since 1 October'",
    "simple": "the reader: 'for a customer who is not technical'",
    "don't": "what to do instead (keep 'don't' for hard limits)",
    "do not": "what to do instead (keep 'do not' for hard limits)",
}


def vague_spots(prompt):
    found = []
    for word, advice in VAGUE.items():
        for match in re.finditer(rf"\b{re.escape(word)}\b", prompt, re.IGNORECASE):
            found.append((match.start(), word, advice))
    return sorted(found)


prompt = ("Write a short update about the recent outage for customers. "
          "Keep it simple and don't use jargon. Mention a few things they can do.")
for position, word, advice in vague_spots(prompt):
    print(f"{word!r:<9} at {position:>3}: replace with {advice}")

'short'   at   8: replace with a number: 'at most 3 sentences'
'recent'  at  31: replace with a period: 'since 1 October'
'simple'  at  68: replace with the reader: 'for a customer who is not technical'
"don't"   at  79: replace with what to do instead (keep 'don't' for hard limits)
'a few'   at 105: replace with an exact count: 'three'

Say what to do, not only what not to do

A positive instruction describes the behavior or form you want: "Write in flowing prose paragraphs". A negative instruction only names what to avoid: "Do not use Markdown". Anthropic's guide advises telling the model what to do instead of what not to do, and uses exactly that pair as its example: instead of "Do not use markdown in your response", try "Your response should be composed of smoothly flowing prose paragraphs."

The reason is easy to see from how a model writes. A negative instruction rules out one option but leaves every other option open, so the model still has to guess what you do want, and it may pick something just as unwanted. It also puts the unwanted thing into the text the model is continuing from. A positive instruction points straight at the target.

The last row shows that negative instructions still have a place: hard limits ("never", "do not") are clearer as prohibitions. Keep them, and add what to do instead. The second row is a special case worth knowing: "don't make things up" on its own is a weak instruction; Microsoft's guide says instructions such as "only write true facts" might not be adequate on their own. Giving the facts and a way out works better; see Reducing Hallucinations.

Explain why

An instruction rationale is the reason you give along with an instruction, such as who will read the answer or what it will be used for. It lets the model apply the intent of the instruction to cases the instruction itself did not name. Anthropic's guide shows the effect with an example: "NEVER use ellipses" is weaker than "Your response will be read aloud by a text-to-speech engine, so never use ellipses since the text-to-speech engine will not know how to pronounce them", because the model can generalize from the explanation, for example by also avoiding other symbols a speech engine may stumble over.

Among the major vendors, Anthropic is the one that states this advice explicitly (as of October 2026). It also matches how briefing people works, and it has a second benefit: the next person who maintains the prompt can see why each rule is there, and can tell which rules may be removed when the situation changes.

Kestrel Energy customers must resubmit meter readings they sent through the customer portal between 08:10 and 09:05 today, because a fault (ticket INC-40217) meant those readings were not saved. Write a message about this for customers. Don't make it too long and don't use jargon.

Kestrel Energy customers must resubmit meter readings they sent through the customer portal between 08:10 and 09:05 today, because a fault (ticket INC-40217) meant those readings were not saved. Write a message about this for customers who are not technical. Use at most five short sentences, because our phone system will read the message aloud to callers waiting in the queue.

Calm, plain wording

Older prompts are often full of capitals: "IMPORTANT", "You MUST", "NEVER EVER". That was a way to get attention from earlier models that tended to skip instructions. Current models follow instructions more closely, and shouting now backfires. Anthropic's guide (as of October 2026) advises to "dial back any aggressive language": where you might have written "CRITICAL: You MUST use this tool when…", normal wording such as "Use this tool when…" works, and the emphatic version can make newer models overdo the instruction, applying it where it does not belong. OpenAI's developer blog makes a related point about its newest models: overly specific guidance that once helped "can now hinder results".

IMPORTANT!!! You MUST ALWAYS include the ticket number. NEVER forget the ticket number!!!

Start every reply with the ticket number, so the customer can quote it when they call back.

The calm version is shorter, says where the ticket number goes and why, and does not suggest that this one rule outranks everything else in the prompt.

What the vendors say

The providers agree on the basics and differ in emphasis. As of October 2026, their published guidance on the points of this page:

"Not stated as a rule" means the advice was not found as an explicit recommendation in that vendor's guide, not that it would hurt. Clear, explained, positive instructions are good briefing practice for any model; where vendors differ, such as the default between advice and action, the safe course is to state what you want.

A checklist before you send

• Would a colleague without background know exactly what to do?
• Is the reader named, and what they already know?
• Is it clear whether you want advice, a draft or a change?
• Is the length a number of sentences, bullets or words?
• Does every "don't" have a "do instead", unless it is a hard limit?
• Do the less obvious instructions come with a reason?
• Is there a way out for missing information ("if the ticket does not say, write 'unknown'")?
• Is it written calmly, without capitals for emphasis?

Clear instructions are one component of a prompt; the others are on Anatomy of a Good Prompt. Standing instructions that apply to every conversation belong in a system prompt or the assistant's custom instructions; see Roles and System Prompts.