Writing Clear, Explicit Instructions

Last lesson covered where instructions go (system vs user). This one is about how to word them so the model literally cannot misread you. It's the highest-leverage, lowest-effort skill in prompt engineering: most 'the AI gave me a bad answer' moments are really 'I gave the AI an unclear instruction.'

The core fact, straight from the generation lessons: the model doesn't read your mind — it fills any gap with the most average, most plausible interpretation. Every vague word is a decision you've silently handed off to a coin flip. Clear, explicit instructions take those decisions back.

As the field put it in 2026: prompt engineering didn't become 'writing longer prompts' — it became writing clearer specs.

You'll learn:

• Why ambiguity quietly wrecks output
• Be specific & quantify — kill vague adjectives
• Say what TO do, not what to avoid (the Pink Elephant problem)
• The 'competent stranger' test, decomposition, and avoiding contradictions

Consider: "Summarize this and keep it short." Sounds clear — but you've left at least four decisions to the model: How short? One line? A paragraph? Bullets or prose? For whom? It will pick the most statistically average reading — and a different one next time, on a different input.

That's the heart of it: ambiguity → inconsistency. Because generation is probabilistic, an under-specified instruction doesn't fail loudly; it produces plausible-but-varied output that's maddening to rely on. The model isn't being difficult — it genuinely can't tell which of several reasonable interpretations you meant.

Every technique below is really one idea: convert the model's guesses into your decisions.

Vague adjectives are invisible ambiguity. 'Brief,' 'professional,' 'detailed,' 'a few' — each means something different to the model every time. Replace them with measurable specs:

Also define ambiguous terms the moment they could be read two ways ('recent,' 'short,' 'high priority'). If you can attach a number, a unit, or a concrete definition, do it. Specificity is the single biggest upgrade you can make to any prompt.

Quick: don't think of a pink elephant. Too late — you just did. Models have the same problem. Telling a model not to do something forces it to process that very concept first, which often makes the unwanted thing more likely.

So reframe every negative instruction as a positive one — tell it what to do instead:

This one change reliably improves compliance. When you catch yourself writing 'don't…', stop and ask 'then what should it do?' — and write that instead.

Here's a simple gut-check for any instruction: could a competent stranger — a smart new hire with zero context about your project — do exactly what you want from this instruction alone?

If not, you're relying on knowledge that's in your head but not in the prompt. The model, like that stranger, doesn't know your conventions, your audience, your definition of 'done,' or last week's meeting. Spell out the implicit:

• Implied: "Format the address." → Explicit: "Format the address as: street, city, state ZIP — US style."
• Implied: "Flag risky transactions." → Explicit: "Flag any transaction over $10,000 or from a new account as risky."

The model is brilliant but contextless about your world. The competent-stranger test surfaces exactly the assumptions you forgot to state.

A tangled paragraph asking for five things at once invites the model to drop one. Break a complex task into explicit, ordered steps — the model follows a numbered sequence far more reliably than a run-on request:

Do the following, in order:
1. Read the support ticket below.
2. Classify it as: billing | technical | account.
3. Write a one-sentence summary.
4. Rate urgency 1–5.
5. Return the result as JSON with keys: category, summary, urgency.

Numbering does two things: it ensures nothing is skipped, and it imposes an order of operations (classify before summarizing, etc.). For genuinely hard reasoning you'll later add explicit 'think step by step' prompting — but even for simple multi-part tasks, a numbered list beats a paragraph.

Conflicting instructions are ambiguity in disguise. "Be comprehensive but keep it very short." "Be creative but stick strictly to the facts." Faced with a contradiction, the model has to pick one side — arbitrarily — so you get inconsistent results and can't tell why.

Audit your prompt for conflicts, especially as it grows: a rule you add today may quietly fight a rule from last week (this is a real hazard in long system prompts). When two goals genuinely tension, resolve it explicitly with priority or scope:

• ❌ "Be thorough but brief."
• ✅ "Give a 2-sentence answer; if the user asks for detail, expand."

One instruction, one unambiguous meaning. If you can read it two ways, so can the model.

Watch all five techniques transform one instruction:

Before (vague, negative, contradictory):

Look at this feedback and give me a good summary — don't make it too
long but be thorough, and don't be negative.

After (specific, positive, decomposed):

Summarize the customer feedback below for a product manager.
1. List the top 3 themes, one bullet each (≤15 words).
2. For each theme, note the sentiment as positive | neutral | negative.
3. End with one concrete, actionable suggestion.
Use plain, neutral language. Base everything only on the feedback given.

The rewrite isn't longer for its own sake — every added word removes a guess. Same model, night-and-day reliability. That's the whole craft: trade ambiguity for specification.

Rewrite the vague ones. Turn each into a specific, positive instruction:

1. "keep it short" → ? 2. "don't use jargon" → ? 3. "make it good" → ?

→ e.g. 1: 'answer in 2–3 sentences.' 2: 'use plain language a 12-year-old understands' (positive beats negation — Pink Elephant!). 3: name the actual quality you want — 'accurate, friendly, with one concrete next step.' Every vague word you replace is a guess you take back from the model.

• "The model will figure out what I mean." No — it fills gaps with the most average guess, differently each time. State it.
• "Telling it what NOT to do is enough." No — negation triggers the Pink Elephant effect; say what it should do instead.
• "Vague adjectives ('professional', 'brief') are instructions." They're ambiguity — replace with measurable specs.
• "A clever long paragraph is best for multi-part tasks." No — numbered steps prevent skipped requirements and fix the order.
• "More rules = better." Only if they don't contradict; conflicting rules make output arbitrary.

• The model fills ambiguity with the most average reading — so every vague word is a guess you handed it. Clarity takes those decisions back.
• Be specific & quantify: replace vague adjectives with numbers, units, and definitions ('briefly' → '3 bullets, ≤12 words').
• Positive framing (Pink Elephant): say what TO do, not what to avoid — 'use plain language' beats 'don't use jargon.'
• Competent-stranger test (spell out the implicit), decompose into numbered steps, and never contradict yourself.
• The goal isn't longer prompts — it's clearer specs: trade ambiguity for specification.

Next: clarity is also structural — we'll use delimiters and XML tags to cleanly separate your instructions from your data, so the model never confuses commands with content.