Prompt
Engineering
A prompt is the request-time context that specifies a task for an LLM.
It does not give the model new parameters. It determines what the model can condition on for this response.
Make the task contract
inspectable.
A real application prompt is assembled from distinct components. Separating them makes ambiguity, evidence boundaries, and failure behaviour reviewable.
Inside the window
does not mean equally used.
Critical evidence can be present but hard for a model to use when it is buried in a long prompt.
Place stable rules clearly; keep evidence close to the task that needs it; test equivalent prompts with the evidence moved.
“CO3 requires application-level questions”
“Create five questions”
Preserve the signal.
Remove the scatter.
As a task grows, consolidate repeated instructions, selected evidence, and decisions into one canonical context record.
Scattered context
Canonical context record
Consolidation reduces token cost and distraction. It can also lose exceptions—keep original sources available and never promote instructions inside untrusted documents.
Use the target language
as a testable choice.
Target-language prompts and examples can preserve terminology, grammar, and local meaning. They are not automatically better than English for every model.
Target-language specification
താഴെയുള്ള വിദ്യാർത്ഥി പ്രതികരണത്തെ
"ശരിയാണ്", "ഭാഗികം", അല്ലെങ്കിൽ
"തെളിവില്ല" എന്ന് ലേബൽ ചെയ്യുക.
OUTPUT
{"label":"...", "evidence":"..."}
What to evaluate
Does a target-language instruction and demonstration improve label fidelity for your intended users?
Or does the model follow English instructions more reliably while still producing the target language?
Target instruction
+ target examples
English instruction
+ target data
Translated prompt
Language-native evaluation set
Examples specify a local
mapping.
Zero-shot gives the task and input. Few-shot also shows representative input–output demonstrations. Neither updates the model’s parameters.
Zero-shot
INPUT: “Exposure to cloud-native systems.”
Use when the task and output are easy to state.
Few-shot
“Implement and test a REST API.”
→ assessable
EXAMPLE
“Exposure to cloud-native systems.”
→ needs_review
NOW: {{OUTCOME}}
Use when a boundary or label meaning is hard to express abstractly.
Choose a technique to resolve
a known failure.
For a multi-step transformation, intermediate artefacts can make work checkable. When facts are missing, a tool observation can ground the next step.
Chain of thought
Useful for hard multi-step tasks when intermediate work can be verified.
Identify stated CO3 constraints.
Select an application-level question form.
Verify outcome alignment before drafting.
A fluent trace is not proof. Prefer inspectable facts, calculations, and plans.
ReAct
Reason → Act → Observation. Use when the task needs current external evidence or controlled computation.
“I need the official moderation rule.”
search_policy("moderation")Retrieved clause 4.2 becomes data for the next step.
Validate tool arguments and require approval for consequential actions.
Do not add a technique
without a measurable reason.
A prompt is a
runtime contract.
The techniques in this chapter refine the same request-time contract: task, constraints, evidence, and required output.
{{ONE CLEAR TRANSFORMATION}}
</task>
<constraints>
{{SCOPE, EXCLUSIONS, AND FAILURE BEHAVIOUR}}
</constraints>
<evidence>
{{DELIBERATELY DELIMITED INPUT WITH SOURCE IDS}}
</evidence>
<output_contract>
{{SCHEMA, LENGTH, AND REQUIRED EVIDENCE}}
</output_contract>
Add examples, consolidation, retrieval, tools, or fine-tuning only when evaluation shows the added complexity is justified.
Version the prompt.
Measure the workflow.
One impressive response is not evidence of reliability. Compare prompt changes on a fixed, representative evaluation set.
Next: Hands-on with LLMs
We will apply these ideas to real model interactions: baseline prompt, structured prompt, evidence-grounded prompt, and evaluation.
Open Chapter 04 →Research: Lost in the Middle · multilingual few-shot learning · Chain of Thought · ReAct