Prompt Engineering Fundamentals
Core principles, cross-tool
Last reviewed
Recommended
Prompt Engineering Fundamentals — Timed Test 3 (10 questions)
No account needed. Answers and explanations arrive when you submit.
What this topic tests
The mix every Prompt Engineering Fundamentals set is built to, and the questions published against it so far. Nothing here is hidden before you start.
| Level | Target share | Published |
|---|---|---|
| Easy | 40% | 20 |
| Medium | 40% | 20 |
| Hard | 20% | 10 |
| Total | 50 |
Prompt Engineering Fundamentals — the theory
What Prompt Engineering Is
Prompt engineering is the practice of writing instructions that get a model to produce what you actually wanted, consistently rather than occasionally. OpenAI defines it as writing effective instructions for a model such that it consistently generates content that meets your requirements; Google describes the same activity as creating natural language requests that elicit accurate, high quality responses. There is no secret syntax and there are no magic words. It is ordinary writing, aimed at a reader who knows a great deal in general and nothing at all about your situation.
The most useful thing to understand early is that it is iterative. Google states plainly that prompt design can sometimes require a few iterations before you consistently get the response you're looking for, and describes the whole activity as test-driven. Because a model's output is not deterministic, the same prompt can give different answers on different days. Your first prompt is a draft, and treating it as one is what separates people who get good results from people who conclude the tool does not work.
Why It Matters
Every mainstream AI assistant takes the same input: plain language, the one part of the system you fully control. These techniques transfer between tools, because all three major vendors document the same core advice in their own words.
The Parts of a Prompt
Google Cloud's documentation breaks a prompt into components, which turns "write a better prompt" into a checklist. The first two are essential; the rest are optional:
- Objective — what you want achieved, including the overarching goal and not only the immediate request.
- Instructions — the step-by-step directions for the task.
- Context — anything the model must refer to and could not otherwise know.
- Persona — who or what the model is acting as.
- Constraints — what the model must and must not do.
- Response format — the structure you want back: JSON, a table, a bulleted list, 200 words.
- Few-shot examples — sample inputs paired with the output you want for them.
- Recap — a short restatement of the constraints and format at the end of a long prompt.
You will not need all eight every time. Knowing which one you left out is the point.
The Habits That Do Most of the Work
Be clear and specific. Google calls this an effective and efficient way to customize model behavior. Anthropic offers a test worth stealing: show your prompt to a colleague with minimal context and ask them to follow it — if they would be confused, the model will be too.
Give it the material. Include the information the model needs instead of assuming it has it. Attaching the actual document beats describing it, every time.
Say what the output should look like, rather than leaving the model to guess the structure.
Make constraints measurable. "Write a brief summary" is a subjective qualifier; "write a summary of three sentences or less" is a constraint. Google's checklist names this exact substitution.
Say what to do, not what to avoid. Anthropic's guidance is to replace "do not use markdown" with "your response should be composed of smoothly flowing prose paragraphs". Positive framing describes a target; a prohibition only rules out one of many wrong answers.
Separate the instructions from the material with delimiters — Markdown headings or XML-style tags. Google adds the rule that matters most in practice: pick one format and use it consistently within a single prompt.
Ask for one thing at a time. If a prompt asks a model to summarise, extract entities, translate and draft an email in one pass, Google's guidance is that it is trying to accomplish too much and should be split. For multi-step work, chain the prompts so the output of one becomes the input of the next.
A Worked Example
Start with a prompt that reliably disappoints:
Summarise this and make it good.
Walk the checklist. There is no objective beyond "summarise", no context, no audience, no measurable constraint, no format, and "good" has no definition. Rewritten:
You are briefing a manager who has not read the attached report and has two minutes. Using only the attached text, write a summary of five bullet points or fewer. Each bullet should be one sentence. Lead with the decision being asked for. If the report does not state a decision, say so rather than inferring one.
Nothing clever happened. A persona set the register, the context was bounded, "good" became five bullets of one sentence each, an ordering rule replaced a hope, and the last sentence told the model what to do when its assumption fails — the step almost everyone skips.
The Order Things Go In
When your prompt contains a long document, order matters. Anthropic's guidance is specific:
- Put the long document or data at the top, above your query, instructions and examples.
- Wrap each document so it is clearly separated from your instructions.
- Put the actual question at the end. Anthropic reports that queries at the end can improve response quality by up to 30 percent in tests, especially with complex, multidocument inputs.
- Ask the model to quote the relevant parts first, then answer from those quotes.
Google makes the general version of the point: the order of content in a prompt can affect the response, so reordering is worth trying when one underperforms.
Common Misconceptions
- "Shorter prompts are better prompts." Length is not the variable; completeness is.
- "There are magic words." Google's checklist says to remove language that tries to influence performance through emotional appeals, flattery or artificial pressure, and states that model performance will no longer improve and in many cases will get worse.
- "Examples are always required." Examples show a format rather than describe it, but Google warns that too many can make a model overfit, and Anthropic warns that examples which are too alike teach unintended patterns.
- "Asking for step-by-step reasoning always improves the answer." It often helps, but it costs length and latency, and Anthropic notes that a general instruction often beats a hand-written step-by-step plan.
- "A prompt that works today will work everywhere." OpenAI is explicit that different model types need to be prompted differently, and that even different snapshots within one family can produce different results.
- "If the output is wrong, the prompt needs more words." Often it needs fewer and better ones. Google's checklist puts typos, undefined jargon, contradictions and redundant restatement at the top of the list.
- "Prompting can fix anything." Anthropic notes that not every failure is best solved by prompt engineering — some are better solved by changing the model.
Verify What Matters
A confident tone is not evidence of correctness. Where a claim is recent, obscure or consequential, either give the model the source material or use a tool that grounds it in one — Google's guidance is that search grounding should be enabled whenever a model may need to know obscure or recent facts. Asking a model to check its answer against stated criteria catches real errors cheaply, and is not a substitute for checking what matters. And text you paste into a prompt is instructions as far as the model is concerned: Google's checklist flags untrusted user input inserted into a prompt as a major security risk.
What the Questions Cover
This topic's bank is built to the blueprint shown on this page: 40 percent easy, 40 percent medium and 20 percent hard. Easy items check that you hold a concept correctly. Medium items put you in a situation and ask what to do. Hard items give you two defensible options and a constraint. Roughly a third of the bank is scenario-based.
Where to Go Next
Advanced Prompting Techniques goes deeper on chain-of-thought, few-shot patterns and structured outputs, and Prompt Engineering for Code covers what changes when the output is a program. For the same craft inside one product, see Claude Prompting Best Practices, ChatGPT Basics or Gemini Basics. Claude AI Basics covers using an assistant at all, and AI Agents Basics covers what changes when one is given tools.
Sources
All read 2026-08-09. Anthropic — Prompting best practices · Google — Prompt design strategies and Overview of prompting strategies · OpenAI — Prompt engineering
Sample questions
Three questions from this topic, with the answer and the reasoning shown.
Q1EasyA model stops mid-sentence well before it has finished answering. Which setting is the first thing to check?
- The temperature, since low values make the model stop early
- The maximum number of tokens the response is allowed to generateCorrect
- The size of the prompt, because a long prompt shortens the reply proportionally
- The number of examples included, since each one consumes part of the answer
Explanation
The principle — an answer cut off mid-sentence is usually a budget being hit, not the model losing its way.
Why the key is correct — Google describes the maximum output tokens setting as specifying the maximum number of tokens that can be generated in the response, and gives the rough conversion: a token is about four characters, and 100 tokens is roughly 60 to 80 words. That makes the ceiling easy to sanity-check against the length you actually need.
Why the others are wrong — temperature changes which words are chosen rather than how many are allowed. Prompt length does not shorten the reply one for one. And examples consume prompt space rather than the response allowance.
Remember this — estimate the words you need, convert roughly, and check the ceiling before rewriting the prompt.
Sources — Google's Prompt design strategies.
Q2EasyAnthropic advises making the examples in a prompt diverse. What problem is that advice guarding against?
- The prompt growing long enough to crowd out the actual question at the end
- Inconsistent formatting between the examples producing an output shape you cannot predict
- The model refusing the task because no single example matches the request exactly
- The model picking up a pattern you never intended to teach itCorrect
Explanation
The principle — A model generalises from whatever your examples have in common. If they share something accidental, it learns that too.
Why the key is correct — Anthropic's guidance is to make examples diverse enough that the model does not pick up unintended patterns, and to cover edge cases. Three examples that all happen to be one sentence long teach "answer in one sentence" whether you meant it or not.
Why the others are wrong — Varied examples cost no more room than repetitive ones. Inconsistent formatting is a real but separate fault — you want varied content and identical structure. And a model will attempt a task with no matching example at all.
Remember this — Vary the content of your examples. Keep their shape identical.
Sources — Anthropic, Prompting best practices.
Q3EasyAnthropic notes that not every failing result is best solved by prompt engineering. What example does it give of a fix that lies outside the prompt?
- Raising the temperature so the model explores more possible responses
- Selecting a different model, which can improve latency and cost more easilyCorrect
- Splitting the task into a chain of smaller prompts run in sequence
- Rewriting the prompt in a different language, which changes how it is interpreted
Explanation
The principle — Prompting is one lever among several. Knowing which failures it cannot reach stops you from tuning wording against a problem that lives elsewhere.
Why the key is correct — Anthropic's overview states that not every success criterion or failing evaluation is best solved by prompt engineering, and gives the example that latency and cost can sometimes be improved more easily by selecting a different model. That is a change to the system rather than to the text.
Why the others are wrong — Rephrasing and chaining are both prompting techniques. And temperature changes how varied the output is, not how good it is.
Remember this — Ask whether better wording could possibly fix this. Sometimes the honest answer is no.
Sources — Anthropic, Prompt engineering overview.
Practise all 50 questions
Every published question in Prompt Engineering Fundamentals, with its answer and explanation.
- A model stops mid-sentence well before it has finished answering. Which setting is the first thing to check?easy
- Anthropic advises making the examples in a prompt diverse. What problem is that advice guarding against?easy
- Anthropic notes that not every failing result is best solved by prompt engineering. What example does it give of a fix that lies outside the prompt?easy
- Anthropic suggests replacing "do not use markdown in your response" with "your response should be composed of smoothly flowing prose paragraphs". Why is the second form stronger?easy
- Google advises replacing "write a brief summary" with "write a summary of three sentences or less". What makes the second version better?easy
- Google recommends enabling search grounding whenever a model may need to know obscure or recent facts. What problem does that address?easy
- Google's checklist flags a prompt that asks a model to summarise, extract entities, translate and draft an email in one pass. What is the fault, and the fix?easy
- Google's prompt-health checklist tells you to check a prompt for typos before concluding the model is at fault. Why?easy
- Google's prompt-health checklist warns against leaving the model to guess the structure of the output. What does it advise instead?easy
- How is prompt engineering best described?easy
- In a model's generation settings, what does the temperature control?easy
- What distinguishes a zero-shot prompt from a few-shot prompt?easy
- What do worked examples in a prompt communicate more effectively than prose instructions do?easy
- What does assigning a model a role or persona actually change?easy
- What does it mean to say that prompt engineering is iterative?easy
- A first response is close but not what you wanted. What is the recommended next move?easy
- What is the purpose of using delimiters such as Markdown headings or XML-style tags in a prompt?easy
- Which two components does Google Cloud describe as the essential parts of a prompt, with the rest treated as optional?easy
- Why is a short prompt not necessarily a good prompt?easy
- You want a model to answer questions about a company policy document. What is the most reliable way to make sure it works from the real policy?easy
- A classification prompt carries four worked examples. Three are laid out as "Input:" and "Output:" on separate lines; the fourth uses a dash and puts both on one line. Results are inconsistent in shape. What does this indicate?medium
- A colleague asks a model for "a short, professional summary" of a meeting transcript. Each time they run it they get a different length and a different level of formality, and they are becoming convinced the tool is unreliable. What is the actual fault?medium
- A prompt asking a model to categorise a book returns the right category but as a full explanatory sentence, when you needed one of four fixed labels. Which iteration strategy does Google demonstrate for this?medium
- A prompt for customer replies says: "Keep it short. Be thorough. Do not leave anything out. Aim for brevity." Replies come back at wildly varying lengths. Which two checklist faults are present?medium
- A prompt for release notes reads: "Don't be too technical. Don't use jargon. Don't make it too long. Don't bury the important changes." The notes come back bland and oddly ordered. What is the best revision?medium
- A prompt instructs a model to "always respond in formal British English", and one of its three worked examples is written in casual American phrasing. Outputs are inconsistent. What is the fault?medium
- A prompt opens with "This is EXTREMELY important to my career and something terrible will happen if you get it wrong." What does Google's guidance say about this kind of language?medium
- A prompt pastes in a long support article and asks a question about it, but the model's answer keeps drifting into general advice that is not in the article. Which addition most directly fixes this?medium
- A prompt that normally works starts returning "I'm not able to help with that, as I'm only a language model." The request is ordinary and clearly within what the tool does. What is this, and what does Google suggest trying?medium
- A prompt uses XML-style tags around its instructions, Markdown headings around its context, and blank lines to separate its examples. It works, but unpredictably. What does the guidance say about this?medium
- A script sends a prompt asking a model to extract five fields from an invoice, and a downstream program parses the reply. The extraction is accurate but the program breaks every few runs because the reply's shape changes. What is the appropriate fix?medium
- A team's support assistant is told in its opening message to "act like a friendly senior support agent", but over a long conversation it drifts back to a neutral, generic voice. What does the guidance identify as the fault?medium
- Google warns that including too many examples in a prompt can cause a model to overfit to them. What does that look like in practice?medium
- In a chained sequence of prompts, what defines the relationship between one step and the next?medium
- Why is breaking a complex request into smaller prompts generally more effective than sending one large prompt?medium
- You are adding a prompt to an automated test suite, and the test can only be meaningful if the same input returns the same output on every run. Which setting gives you that?medium
- You are building a prompt that includes three long reports and then asks one analytical question about them. Where should the question go, and why?medium
- You are building a tool that drops a customer's message into a prompt template before sending it to a model. Google's checklist flags this pattern. What is the concern?medium
- You are deciding whether to add "work through this step by step before answering" to a prompt that classifies incoming messages into three categories. What is the relevant trade-off?medium
- You ask a model why your team's deployment failed, describing the error message from memory and summarising what the pipeline does. The answer is plausible, generic, and does not match what actually went wrong. What should you change first?medium
- A compliance prompt supplies four long policy documents and asks which of them govern a described situation. The answers are usually right but occasionally attribute a rule to the wrong document, and every answer must be traceable to its source. Which combination of changes best serves that requirement?hard
- A moderation service classifies 400,000 short posts a day into four categories. Accuracy is acceptable but a small band of genuinely ambiguous posts is misclassified. Adding a reasoning instruction fixes most of that band in testing, but raises median response time above the service's stated ceiling. Latency is a hard constraint; accuracy on the ambiguous band is desirable. What is the best response?hard
- A prompt extracts a delivery date and a tracking number from customer emails. It works on well-formed emails. When a field is absent the model supplies a plausible value, and downstream systems have no way to tell an inferred value from a real one. What is the most reliable change?hard
- A prompt has been revised eleven times over two weeks. Each revision added a sentence, and the current version contradicts itself in two places and restates one instruction three ways. Output quality has declined since revision four. You can spend one working session on it. What is the best use of that session?hard
- A prompt that tags support tickets by product area carries eight worked examples. All eight are billing tickets, all are two sentences long, and all are laid out identically. Billing tickets are tagged well; everything else is tagged as billing surprisingly often. You may change the examples but not their number. What change is most likely to help?hard
- A prompt tuned carefully over months against one model is moved to a newer model from the same family. Output quality drops in ways nobody can characterise precisely. The team wants to prevent this recurring on the next upgrade. What is the most durable response?hard
- A weekly report is produced by one prompt that reads six data files, summarises each, finds cross-file trends, and drafts an executive note. The final note is usually good but occasionally states a trend that contradicts the underlying files, and nobody notices until a reader queries it. Total cost may rise, but errors must become detectable. What is the strongest change?hard
- An internal assistant answers questions about your company's products. It is fluent and confident, but it invents product details that have never existed, and no rewording of the prompt has reduced the rate. The product catalogue is internal and changes weekly. What does this pattern indicate?hard
- One prompt drafts alternative marketing taglines and should produce a fresh set each run. Another assigns each support ticket one of six fixed labels and must assign the same label to the same ticket every time. Both run on the same model. How should the generation settings differ, and why?hard
- Two drafts of a prompt exist for an internal tool that explains error messages to junior engineers. One opens "You are a patient senior engineer explaining to a new graduate." The other lists six rules about vocabulary, length, and assumed knowledge. Both perform similarly in testing. Which consideration should decide between them?hard
Frequently asked
What people ask about prompt engineering fundamentals.
What is prompt engineering, in plain terms?
Why did I get a vague answer when my question seemed clear?
Do I need to include examples in my prompts?
Does being polite, or urgent, or threatening change the answer?
Should I ask the model to think step by step?
Will a prompt that works in one tool work in another?
More Prompt Engineering topics
Related guides
How it works · 11 min read
Why the model can't count the letters in a word
Strawberry has two r's, your 100-word answer runs to 137, and the limerick does not rhyme. Those are not three mistakes. Text becomes tokens before the model sees it, and everything below the token — letters, characters, sounds — was discarded at the door.
How it works · 11 min read
Where you edit your prompt decides what it costs
The session was fast for twenty turns, then you added one line to the top of a file and the next answer crawled. A prompt cache is keyed on an exact prefix, so cost and latency depend on where you changed something, not how much. The ordering rule that falls out of it.
How it works · 9 min read
Where an instruction belongs: prompt, system prompt, or project instructions
Every assistant offers the same five containers for an instruction, and the same sentence is a permanent rule in one and a single-turn suggestion in another. The placement rule across vendors: what survives a new conversation, what survives a context trim, what gets re-billed every turn, and what outranks what.