Zero-Shot Instruction Writing

"Rewrite this error message for a non-technical user" has no canonical answer. For every correct rewrite there are a thousand more that are also correct, so an example set would pin one style and present it as the only style. Some tasks resist demonstrations for exactly that reason: the output space is open, the input shapes are unbounded, or you ship faster writing one precise instruction than curating five pairs.

Zero-shot prompting is instruction alone — no demonstrations, no Input/Output pairs. The entire contract has to survive in prose, which makes wording the whole engineering surface.

Two rules keep it honest. First, pick a verb that names the transformation: classify, extract, rewrite, rank. "Improve this text" leaves the model to guess the axis — grammar? length? tone? — and it will guess differently on Tuesday than it did on Monday.

Second, name who reads the output. System Prompt Design carries standing scope and refusal rules; the per-request instruction carries the audience. "For a public status page" and "for an internal postmortem" produce different vocabulary from identical input, and the model cannot infer which one applies.

A zero-shot instruction is four slots plus an audience line. Here is a vague request next to the same request written as a contract:

BEFORE: "Clean up these customer quotes."

AFTER:  Rewrite each customer quote for a status page.
        - one bullet per quote, max 12 words, present tense
        - no brand names; keep numbers exactly as given
        - if a quote has no measurable outcome, write "Fix in progress"
        Audience: customers reading a public incident page.

The before version defines no input, no output shape, no length limit, and no policy for quotes that carry no result — so the model invents all four, differently each run. Running the after version:

QUOTES = [
    "We lost access for about four hours Tuesday, team still digging",
    "Latency dropped by 38% after the patch on March 4",
    "Escalated to the vendor, no update yet",
]

# messages:
#   system -> scope + tone (standing rules from the system prompt)
#   user   -> the AFTER instruction above, followed by QUOTES

Output:

- Access loss still under investigation — four hours Tuesday
- Latency down 38% after the March 4 patch
- Fix in progress

Two lines decide whether that output survives downstream:

• max 12 words is countable. "Concise" is not, and uncountable adjectives are the usual source of "sometimes it's too long."
• The failure clause converts an empty case into a specified case. Without it the model either drops the third quote or invents an outcome, and both failures are silent — a dropped row looks like a short invoice, not like an error.

Write the instruction as if handing it to a contractor on their first day: what comes in, what goes out, what the limits are, and what to do when the input does not fit the rule. When a task also needs intermediate computation rather than a transformation, the instruction alone stops being enough — Chain-of-Thought Prompting adds the reasoning step.

Give a model records where some fields are empty and ask it to summarize, and it fills the gaps. Not out of malice: an instruction that says nothing about absent data leaves absence undefined, and an undefined case gets the most fluent answer available.

INSTRUCTION = """Extract from each record: name, order_id, shipped_date.
Rules:
- Copy values verbatim; never infer a date.
- If a field is absent, output null for that field.
- Output one JSON object per line, keys in the order listed."""

record = {"name": "A. Okafor", "order_id": None}   # shipped_date absent

Output:

{"name": "A. Okafor", "order_id": null, "shipped_date": null}

Without the absence rule, the same input has produced "shipped_date": "2026-03-14" — a plausible Tuesday — and the row entered the warehouse queue looking complete.

Vague instructions fail in patterns you can grep for:

Every row follows the same move: replace the adjective with a count, replace the assumption with a rule. Exact-match checks in your code finish the job — if the instruction says null for absent fields, a validator that rejects any other value catches the run where the model decided to be helpful instead.

Precision fixes what the model produces. When accuracy still slips because the answer has to be computed from several constraints, the missing piece is the reasoning itself, which is where Chain-of-Thought Prompting begins.