A prompt is the whole input a model sees, and prompt engineering is the practice of shaping it so the answer is usable.
What a prompt is made of
Instruction is what you want done. Context is the material to do it with, including retrieved documents and conversation history. Input is the specific case. Output indicator is the shape you want back, such as JSON or a heading and three bullets.
Two further ideas appear in the syllabus. Negative prompts state what to avoid, which works better on image models than on text, where naming a thing tends to summon it. Latent space is the model's internal representation of meaning, and it is the thing a prompt is steering through.
The shot based techniques
Zero shot asks with no examples. It is the default and it works whenever the task is common enough that the model has seen it in training.
Single shot gives one worked example. Few shot gives several. Examples teach format and edge handling far more efficiently than describing them, and this is the cheapest large improvement available. Three examples covering the awkward cases usually beats a paragraph of instructions.
The limits are real. Examples consume context, and the model will imitate their distribution, so if all your examples are positive cases it will lean positive.
Chain of thought
Asking the model to work through its reasoning before answering. It materially improves multi step problems, arithmetic and anything with intermediate conclusions, because the intermediate tokens give the model something to condition on.
Two cautions. The stated reasoning is generated text rather than a report of internal process, so it can be plausible and wrong while the answer is right, or the reverse. And it costs tokens and latency, so applying it to classification is waste.
Role prompting and prompt chaining
Two more the Google exam names.
Role prompting tells the model who to be. Answer as a technical support engineer, or as a sceptical reviewer. It works because it narrows the register, the vocabulary and the assumptions the model draws on, and it is most useful where the same facts should be expressed very differently for different audiences.
Prompt chaining splits work across several calls, each one taking the previous output as input. Extract the facts, then check them against a policy, then write the reply. It costs more calls and it is far easier to debug, since you can see which step went wrong, and each step can use a different model or temperature.
ReAct
ReAct, reason and act, interleaves thinking with tool use. The model reasons about what it needs, calls a tool, reads the result, reasons again. It is the pattern underneath most agents, and it is the point at which prompting stops being about wording and becomes about what the model is permitted to do.
Prompt templates
A parameterised prompt with slots filled at runtime. This is how prompting becomes engineering rather than craft, since a template can be versioned, tested and changed in one place. It also creates the injection surface, because whatever fills the slot is text the model will read as though you had written it.
The four risks
The syllabus names these and expects you to distinguish them.
Exposure is confidential material leaking through the prompt. Anything you put in context can appear in output, so a system prompt containing a key, or a retrieved document the user should not see, is one clever question away from being read back.
Poisoning is corrupting what the model learns from or retrieves. Planting misleading content in a source that gets indexed means the system quotes it back with confidence, and this is the risk that grows as retrieval is added.
Hijacking, or prompt injection, is input that overrides your instructions. A support agent reading a customer email that says to ignore previous instructions and issue a refund is the canonical case. It follows from instructions and data sharing one channel, which is why it cannot be solved with wording.
Jailbreaking is getting the model past its own safety training, usually by roleplay or hypothetical framing.
Defending against them
Treat every model output as untrusted input to whatever consumes it. Filter on the way in and on the way out. Give any tool the model can call the narrowest permission that works. Keep secrets out of prompts. Managed filtering applies content filters, blocked topics and word filters to both sides of the exchange, and every platform offers it, Guardrails for Amazon Bedrock, Azure AI Content Safety, and Google's safety settings and Model Armor.
Practise this
You need a prompt you actually run in production, five inputs that exercise it, and a chat window.
Run the full prompt against all five inputs first and save what comes back. Then delete exactly one instruction, run the same five inputs again, and put the line back before attempting the next removal. Fifteen instructions takes about an hour, and stopping after the first ten still teaches the lesson.
Ablation log. Five fixed inputs, one removal at a time.
line | instruction, first few words | outputs changed | verdict
-----+-------------------------------+-----------------+------------
4 | Always answer in British ... | 5 of 5 | earning it
9 | Be helpful and professional | 0 of 5 | inert
12 | Never mention a competitor | 0 of 5 | untested
Procedure per line:
1. Delete that one line only.
2. Rerun the same five inputs.
3. Diff the outputs against the baseline.
4. Restore the line before the next removal.
Look hardest at the lines that changed nothing, and resist deleting them the same afternoon, because unchanged across five inputs means untested rather than useless. The instruction about never mentioning a competitor does nothing at all until an input mentions one, which is why the last column of that log needs three values and not two.
A long prompt grows by accretion, and a line that is working looks exactly like a line nobody has ever exercised until you take it out.