Prompting basics

This mini-book is for Level 1 User. You are improving a prompt for your own work, using permitted material and checking every result yourself.

2. Nearly right is still wrong

You need three facts from a short abstract before a meeting: what was tested, how many samples were used, and which condition performed better. You ask, “Summarise this.” The answer sounds polished, mentions the assay and sample count, then confidently says one temperature worked best. The abstract never says that.

You retry. This time the answer avoids the invented result but omits the sample count. A third attempt returns a long paragraph when you needed three fields you could inspect in seconds. Each output is nearly right in a different way.

The task is small and affects only your notes, but guessing is wasting time. You need a prompt that states the job, limits the evidence, defines the output, and demonstrates the pattern. You also need a disciplined way to revise it, because changing everything at once will not show what solved the problem.

3. After this you can

• Write a prompt with role, task, constraints and an example.
• Fix a bad output by changing one thing at a time.
• Recognise when the prompt is not the problem.

4. Prerequisites

• T02-L01 · Getting good answers from a chatbot.
• One approved chatbot, or the supplied illustrative outputs if you are working offline.
• A text editor or notes document in which to save three prompt versions and their outputs.
• One short public, synthetic, or explicitly approved source for the exercise.

Do not paste personal data, confidential company information, unpublished research, credentials, customer records, or production data into an unapproved service. The examples in this book are entirely synthetic.

5. The idea in one page

A useful prompt is a small, reviewable task brief. For a simple Level 1 task, build it from four parts.

Role: set the working stance

The role tells the chatbot what kind of work it is doing: “You are an assistant producing a reviewable extraction.” This can focus vocabulary and priorities. It does not give the chatbot expertise, authority, access, or factual reliability. “Act as a scientist” cannot reveal an experimental result that is absent from the source. “Act as a lawyer” cannot approve a contract.

Task: name one job

Use a concrete verb and object: extract three fields, classify each item, rewrite this paragraph, or compare two supplied passages. “Help with this” and “make it better” force the chatbot to choose the job. If you cannot describe the task clearly, settle that decision before adding more prompt text.

Constraints: make success inspectable

Constraints state the required shape and boundaries. Name labels, counts, length, exclusions, and the treatment of uncertainty. For source-based work, say “Use only the supplied text” and define an exact response for missing information. These instructions do not guarantee truth. They make a violation easier for you to spot.

An output specification is part of the constraints. “Be concise and professional” is subjective. “Return exactly three labelled bullets and no commentary” is observable. You can count the bullets and compare each value with the source.

Example: show the pattern

When format or classification remains ambiguous, add one small input/output example. It should resemble the task, demonstrate the desired pattern, and stay separate from the live input. For a simple task, one representative example is often more useful than a list of vague adjectives. That is a practical teaching rule, not a guarantee. An example can improve consistency, but it cannot supply missing evidence.

Improve by changing one variable

Save V1, its output, and the failure you observed. Create V2 by changing one named prompt element. Run the same source and compare. Then create V3 with one further change. This controlled sequence shows which instruction affected the result. If you alter the prompt, source, task, and tool together, “better” is only a guess.

Finally, diagnose the boundary. If the requested fact exists but the output misses it, revise the task, constraints, or example. If the fact is absent, stop prompting. Supply permitted context or change the question. More context is covered in T03-L02; finding answers across documents is covered in the T04 track.

6. The worked example: three controlled revisions

Both framings use the same task skeleton and checks. In each one, preserve the source while moving from V1 to V3. The outputs below are illustrative: your approved chatbot may phrase them differently. Judge the visible requirements, not whether the wording matches exactly.

Use these checks after every run:

1. Are there exactly three labelled bullets?
2. Does each extracted value appear in the supplied text?
3. Is every absent value marked Not stated in the supplied text.?
4. Is there any advice, interpretation, or extra commentary?

Lab framing: extract fields from an abstract

The synthetic fixture is deliberately incomplete:

Abstract: We tested the BlueRiver assay with 24 samples. The pilot used two
temperature settings. The abstract does not state which setting performed better.

V1: baseline request

Summarize this.

Abstract: We tested the BlueRiver assay with 24 samples. The pilot used two
temperature settings. The abstract does not state which setting performed better.

Illustrative V1 output:

The BlueRiver assay was evaluated on 24 samples under two temperature settings.
The pilot compared performance across the settings to identify the better condition.

Observed effect: the prose is readable, but there are no inspectable fields. The last phrase also suggests a purpose that the fixture does not state. Record V1 — generic prose; required fields and missing-value handling absent.

V2: add the task brief

Only one prompt element changes: the vague request becomes a brief containing the role, task, exact output, source boundary, and missing-value rule.

You are an assistant producing a reviewable extraction.

Task
Extract the requested fields from the supplied text.

Output
Return exactly three labelled bullets:
- Subject:
- Quantity or count:
- Date or deadline:

Constraints
Use only the supplied text.
Do not infer missing values.
If a field is absent, write: Not stated in the supplied text.
Do not add advice or commentary.

Text
<text>
Abstract: We tested the BlueRiver assay with 24 samples. The pilot used two
temperature settings. The abstract does not state which setting performed better.
</text>

Illustrative V2 output:

- Subject: BlueRiver assay tested using two temperature settings.
- Quantity or count: 24 samples.
- Date or deadline: Not stated in the supplied text.

Observed effect: the result now has three countable fields, uses the given sample count, and marks the absent date without guessing. Record V2 — task brief produced inspectable fields and explicit uncertainty.

The prompt still cannot answer which setting performed better. That information is absent. Rewording the role or adding “be accurate” cannot recover it.

V3: add one representative example

Keep every line of V2. Add only this example immediately before Text:

Example
Input: The Cedar test used 12 records. No review date was provided.
Output:
- Subject: Cedar test.
- Quantity or count: 12 records.
- Date or deadline: Not stated in the supplied text.

Illustrative V3 output:

- Subject: BlueRiver assay.
- Quantity or count: 24 samples.
- Date or deadline: Not stated in the supplied text.

Observed effect: the output follows the requested pattern more narrowly: the subject is a compact value rather than a sentence. The facts remain unchanged. Record V3 — one example made the field pattern more consistent.

Mira saves all three prompts and outputs. She then checks BlueRiver assay and 24 samples against the fixture. She does not add a preferred temperature to her notes because the source does not provide one.

Company framing: extract fields from a supplier email

Now use the identical revision sequence with a different synthetic fixture:

From: Northstar Supplies
Subject: March delivery
Please confirm that 18 units arrived. The email does not state a payment due date.

V1: baseline request

Summarize this.

From: Northstar Supplies
Subject: March delivery
Please confirm that 18 units arrived. The email does not state a payment due date.

Illustrative V1 output:

Northstar Supplies is following up on the March delivery of 18 units and requests
confirmation of receipt so payment can proceed by the due date.

Observed effect: the answer captures the sender and quantity, but it is unstructured and invents a connection between confirmation, payment, and a due date. Record V1 — generic prose; unsupported payment sequence added.

V2: add the task brief

Replace only the vague request with the same brief used in the Lab framing:

You are an assistant producing a reviewable extraction.

Task
Extract the requested fields from the supplied text.

Output
Return exactly three labelled bullets:
- Subject:
- Quantity or count:
- Date or deadline:

Constraints
Use only the supplied text.
Do not infer missing values.
If a field is absent, write: Not stated in the supplied text.
Do not add advice or commentary.

Text
<text>
From: Northstar Supplies
Subject: March delivery
Please confirm that 18 units arrived. The email does not state a payment due date.
</text>

Illustrative V2 output:

- Subject: March delivery from Northstar Supplies.
- Quantity or count: 18 units.
- Date or deadline: Not stated in the supplied text.

Observed effect: the unsupported payment sequence disappears, and the missing deadline is explicit. Record V2 — source boundary removed inference and exposed the absent deadline.

V3: add one representative example

Keep V2 unchanged and insert the same Cedar example before Text:

Example
Input: The Cedar test used 12 records. No review date was provided.
Output:
- Subject: Cedar test.
- Quantity or count: 12 records.
- Date or deadline: Not stated in the supplied text.

Illustrative V3 output:

- Subject: March delivery.
- Quantity or count: 18 units.
- Date or deadline: Not stated in the supplied text.

Observed effect: as in the Lab framing, the example tightens the field shape without changing supported facts. Record V3 — one example made the field pattern more consistent.

Jonas compares each value with the email fixture. He can report the delivery subject and quantity. He cannot report a payment deadline. If the deadline is necessary, he must obtain an approved source that states it; another prompt revision is not the fix.

7. What goes wrong

Politeneness replaces a requirement

Symptom: “Please make this really clear and professional” produces variable lengths and formats.

Fix: replace adjectives with observable requirements such as three labels, one sentence per field, and no commentary.

The output invents an absent value

Symptom: a date, result, owner, or deadline appears even though it is not in the source.

Fix: state the source boundary and exact missing-value response, then compare every extracted value with the source.

“Professional” has no example

Symptom: the content is usable, but the shape or tone changes on repeated runs.

Fix: provide one short, representative input/output example that demonstrates the pattern without adding live facts.

Five changes hide the useful one

Symptom: the final output looks better, but you cannot say whether the new role, format, example, source, or tool caused it.

Fix: hold the task and fixture constant. Change one named element, save the output, and record the observed effect.

Missing context is treated as bad wording

Symptom: repeated prompt edits still cannot produce a supported result or deadline.

Fix: stop prompting. Supply the permitted source that contains the fact, narrow the question, or mark the answer unknown.

A successful prompt is not saved

Symptom: the prompt works once, but next week you cannot reproduce or explain the result.

Fix: save the prompt version, fixture, output, date, and pass/fail note together.

Fluent output skips verification

Symptom: a polished extraction is copied into your notes without checking names, counts, dates, or omissions.

Fix: compare each field with the supplied source. Treat fluency as presentation, not evidence.

8. Do it yourself: a 25-minute prompt repair

Minutes 0–4: choose one short public, synthetic, or approved text. Define three fields that should be extracted. Include one field that is genuinely absent so you can test the missing-value rule.

Minutes 4–8: run V1, a one-line request such as Summarize this. Save the exact prompt and output. Name one visible symptom.

Minutes 8–15: create V2 by replacing the vague request with a role, one extraction task, exactly three labelled output fields, a source-only constraint, and an exact missing-value response. Keep the source unchanged. Save the output and record the effect.

Minutes 15–20: create V3 by adding only one representative input/output example. Run the same source again. Save the output and state what changed. Do not claim an improvement unless it is visible.

Minutes 20–25: check all three V3 fields against the source. If the missing field contains a guessed value, mark the run as failed. If a required fact is absent, do not keep rewriting the prompt; record that permitted context is needed.

Use this compact record:

9. Exit check

Deliver exactly one artifact: one prompt record containing V1, V2, and V3, each paired with its output and one sentence describing the observed effect of that revision.

It passes when the source is unchanged across all three runs, each revision changes only the named prompt element, the final output contains the required fields, and every final value is supported by the source or uses the exact missing-value response.

10. Rule to remember

Change one thing, then look.

11. Further reading & tools

• Taught: T02-L01 · Getting good answers from a chatbot — supplies approved material, audience, examples, and exclusions in one request.
• Taught: T03-L02 · Context engineering — continues when the instruction is sound but the necessary information is missing or poorly assembled.
• Taught: T04-L01 · Ask questions about your own files — retrieves answers from a document collection and checks citations against sources.
• Catalogued: OpenAI prompt engineering (opens in a new tab) — primary guidance on clear instructions, relevant context, output requirements, examples, and evaluation.
• Catalogued: OpenAI evaluation best practices (opens in a new tab) — primary guidance on representative tests for prompt changes.
• Catalogued: Anthropic prompting best practices (opens in a new tab) — primary guidance on direct instructions, constraints, formats, and examples.
• Catalogued: Anthropic prompt engineering overview (opens in a new tab) — primary guidance on success criteria and empirical testing before refinement.
• Catalogued: Tools index — current product references; confirm organisational approval and data handling before use.