Prompt Engineering Basics: Anatomy of a Good Prompt

A librarian types "Write an overdue notice" into an assistant and gets back something polite, generic and slightly wrong: a library name nobody mentioned, a fine amount nobody set, a signature belonging to no one. The model did not misbehave. You left gaps, and it filled each one with the most ordinary guess available. Prompt engineering begins with closing those gaps on purpose.

A prompt is a work order, not a wish

Imagine handing a work order to a very capable contractor who has never seen your building. They write well and know a great deal in general, but they do not know your policies, your tone, who will read the result or what you plan to do with it. Anything not on the work order gets guessed. A prompt is that work order. Short prompts are not wrong, but they delegate every decision to the model's defaults.

The practical habit is to write prompts from five parts. You will not always need all five, yet checking each one takes ten seconds and catches most of the problems beginners hit.

Before and after

Here is the prompt most people start with, followed by a rewrite that uses all five parts. Read the second one as a template: the values in square brackets are filled in by you, or by your program, for each member.

Write an overdue notice for a library book.

ROLE
You are the front-desk assistant at a small public library.

TASK
Draft the first overdue reminder email for one member.

CONTEXT
Member first name: [FIRST_NAME]
Book title: [TITLE]
Due date: [DUE_DATE]
Policy: no fine for the first 7 days overdue; after that the fee is
decided by the front desk and must not be quoted in this email.

CONSTRAINTS
- Friendly and brief: under 120 words.
- Do not threaten or mention collections.
- If any value above is missing, write [MISSING: field name] in its
  place. Never invent a name, date or amount.

OUTPUT FORMAT
Line 1: "Subject: ..." (max 8 words)
Then a blank line, then the email body in plain text.

The second prompt cannot guarantee identical wording on every run, because models sample their output. What it does is narrow the range of acceptable answers so that every run lands inside it. Below is an illustrative reply, shown only to make the format concrete; your own run will differ.

Subject: A gentle reminder about your book

Hi Priya,

Our records show that "The Salt Road" was due back on 4 June. No
worries if life got busy. You can return it at the front desk or
renew it from your account. If you need more time, just reply to
this email and we will sort it out.

Thank you,
The Front Desk

Writing each part well

• Role sets tone and audience. It does not add knowledge: "you are a world-class lawyer" will not make the model know your jurisdiction. Name a realistic job and, if it matters, the reader ("writing to a member who is not a native English speaker").
• Task should be one deliverable with one verb. "Summarise, translate and critique this" is three tasks; run three prompts or number them explicitly.
• Context is where you paste the facts. Wrap pasted material in clear markers such as triple quotes or XML-style tags so the model can tell your instructions from your data.
• Constraints work best when concrete and checkable: a word limit, a banned phrase, a required field. "Keep it short" is a wish; "under 120 words" is a test you can run.
• Output format is the part beginners skip. Say exactly what you want: headings, a table, a list of three, a subject line plus body, JSON. If a program will read the answer, show the exact shape.

Common mistakes and the symptom each one causes

• Several tasks in one prompt. Symptom: one task is done well and another is skipped or done in a single sentence. Fix: split into steps (see the lesson on decomposition and refinement).
• No audience. Symptom: the register is wrong every time and you edit the tone by hand. Fix: say who reads it.
• Leaving out facts. Symptom: invented names, dates, policies or amounts that sound plausible. Fix: supply the facts and add a missing-information rule.
• Vague limits. Symptom: "short" yields forty words on one run and two hundred on the next. Fix: give a number.
• Contradictory constraints. Symptom: "brief but cover everything" silently picks one. Fix: rank the constraints ("if forced to choose, brevity wins").
• Pasted data without markers. Symptom: the model treats part of your data as instructions. Fix: delimit it, and read the lesson on injection and testing.

How this shows up in real projects and interviews

In a product, a prompt like the one above is a template stored next to the code, with the bracketed values filled in by your program for every request. Reviewing a prompt is therefore a normal code-review task: someone asks which fact is missing and what happens when it is. In interviews, a common exercise is to be handed a weak prompt and asked how you would improve it. Walking through the five parts, then saying you would try it on several different inputs rather than one, is a sound answer. Be honest about the limits too: a better prompt shapes the answer, but it cannot supply knowledge the model does not have, which is where retrieval comes in.