Glossary
66 terms from “Prompt Engineering Basics: How to Write Effective Instructions.” Hover the first occurrence in the lesson for its definition.
| Term | Definition | Source |
|---|---|---|
| prompt | The text instruction you give an AI model to tell it what you want — a question, a description, a task, or some mix of the three. It is the only channel through which the model can learn what your task is. | Prompt - Wikipedia |
| large language model (LLM) | An AI system trained on huge amounts of text that can understand natural language and generate new text in response; ChatGPT and Claude are examples. | Large Language Model - Wikipedia |
| Prompt engineering | The systematic practice of designing and refining prompts so a model can act on what you actually need. It is a reusable skill, not a collection of one-off tricks. | Prompt - Wikipedia |
| vague prompt | An instruction that leaves out the information the model needs — no audience, no format, no scope — so the model has to guess your intent. | OpenAI Prompt Engineering Best Practices |
| clear prompt | An instruction that pins down the task, the output format, and the background the model needs, leaving little room for it to improvise. | OpenAI Prompt Engineering Best Practices |
| output quality | How well the model's response matches what you needed — accuracy, relevance, completeness, and correct format together, not just whether the content is right. | Prompt Engineering Best Practices 2026 |
| back-and-forth refinements | The extra rounds of conversation needed to patch a prompt that was underspecified. Research on code generation found explicit specifications cut these rounds by 68%. | Prompt Engineering for Code Generation |
| follow instructions | A model's ability to take in and act on what a prompt actually asks for. As of 2026 models do this well across complex directions, long documents, and multi-step tasks. | IBM Prompt Engineering Guide 2026 |
| token | The unit an LLM uses to process text, roughly a word fragment. Both your prompt and the model's response consume tokens, which is what you pay for and wait on. | OpenAI Prompt Engineering Best Practices |
| role | The identity or perspective you tell the AI to answer from, such as 'you are a senior Python engineer' or 'you are a teacher explaining through analogies'. It sets expertise level and tone. | Anthropic Prompt Engineering Overview |
| task description | The part of the prompt that says exactly what you want done. It has three layers: a verb (summarize, analyze, generate), an object (what it acts on), and a goal (what result to reach). | OpenAI Prompt Engineering Best Practices |
| output format | The structure and style you want the answer in — JSON, a table, three bullets, a fixed set of sections — stated explicitly rather than left to the model. | OpenAI Prompt Engineering Best Practices |
| constraints | The 'only...' and 'don't...' rules that bound the response — length, scope, tone, exclusions, priorities — keeping the model from wandering off task. | OpenAI Prompt Engineering Best Practices |
| context | The background information you supply in the prompt so the model understands the specific situation, audience, and boundaries of the task. | Anthropic Prompt Engineering Overview |
| Audience perspective | A role pattern that frames the answer around who will read it, such as 'you're explaining this to non-technical leadership'. It controls depth and vocabulary. | Anthropic Prompt Engineering Overview |
| jargon | Domain-specific vocabulary whose use should be decided by who is reading. Aimed at the wrong audience it either loses the reader or wastes their time on explanation they don't need. | Anthropic Prompt Engineering Overview |
| template | A prompt whose variable part is replaced by a placeholder, so the same structure can be reused across runs with only the input swapped in. | Anthropic Prompt Engineering Overview |
| review dimensions | The named angles you tell the AI to examine something from — correctness, performance, security, clarity — usually with a priority order. | Prompt Engineering for Code Generation |
| few-shot learning | A technique that guides the model by placing a small number of examples (usually 2-5) in the prompt, so it infers the input-output mapping, the format, and the style from them. | Prompt Engineering Guide - Few-Shot Prompting |
| zero-shot | Prompting with an instruction and no examples at all, leaving the model to apply its own judgment to the task. | Zero-shot Learning - Wikipedia |
| one-shot | Prompting with exactly one example — more guidance than zero-shot, less than few-shot. | Few-Shot Prompting Guide |
| in-context learning | An LLM's ability to infer a rule from examples inside the current conversation and apply it to a new input, with no retraining involved. | Prompt Engineering Guide - Few-Shot Prompting |
| example diversity | Choosing few-shot examples that cover the different kinds of input the task will actually see, instead of several variations on the same case. | Prompt Engineering Guide - Few-Shot Prompting |
| Format consistency | Using the exact same structure and markers across every few-shot example, so the model learns one unambiguous output shape. | Prompt Engineering Guide - Few-Shot Prompting |
| edge cases | The ambiguous, incomplete, or unusual inputs a task will hit in reality — missing fields, mixed signals, extreme values — as opposed to the clean ideal case. | Few-Shot Prompting Guide |
| JSON | A structured data format commonly requested as output for extraction tasks, because a program can parse it directly. | Prompt Engineering Guide - Few-Shot Prompting |
| chain-of-thought | A prompting technique that has the model lay out intermediate reasoning steps before giving a final answer, which raises accuracy on tasks needing multi-step reasoning. | Prompt Engineering Guide - Chain-of-Thought |
| CoT | The standard abbreviation for chain-of-thought prompting, used interchangeably with the full term. | Prompt Engineering Guide - Chain-of-Thought |
| reasoning steps | The visible step-by-step path the model shows from problem to answer, so each link in the logic can be checked instead of taken on faith. | Chain of Thought Prompting Guide |
| let's think step by step | The standard cue phrase appended to a prompt to trigger step-by-step reasoning without supplying any examples. | Prompt Engineering Guide - Chain-of-Thought |
| Zero-Shot CoT | Chain-of-thought triggered by a cue phrase alone, with no examples — the simplest way to get the model to break a problem down. | Prompt Engineering Guide - Chain-of-Thought |
| Few-Shot CoT | Chain-of-thought guided by one or two examples that show the full reasoning process, so the model imitates both the steps and their level of detail. | Prompt Engineering Guide - Chain-of-Thought |
| intermediate steps | The individual calculations or inferences between the question and the final answer. Making them explicit is what chain-of-thought is for. | Prompt Engineering Guide - Chain-of-Thought |
| multi-step reasoning | Tasks where the answer depends on a chain of dependent inferences or calculations — word problems, complexity analysis, root-cause analysis, planning decisions. | Chain of Thought Prompting Guide |
| prompt debugging | Fixing a failing prompt the way you debug code: identify the specific symptom, diagnose which part caused it, change one thing, and verify. | AI Prompt Debugging: Fixing Issues Through Iteration |
| debugging loop | The repeating cycle of run, check the output, identify the problem, diagnose, change one thing, verify against test cases, and record the version that works. | AI Prompt Debugging: Fixing Issues Through Iteration |
| Identify the problem | The first debugging step: naming exactly what's wrong with the output — wrong format, off-target content, missing information, overreach, misread intent, or instability. | AI Prompt Debugging: Fixing Issues Through Iteration |
| Diagnose the cause | The second debugging step: working out which part of the prompt — or which missing part — produced the problem you identified. | AI Prompt Debugging: Fixing Issues Through Iteration |
| one variable at a time | The core debugging discipline: change exactly one thing per iteration so the effect of that change is unambiguous. | AI Prompt Debugging: Fixing Issues Through Iteration |
| iteration | One pass through the change-test-evaluate cycle. Prompts get good through a series of small, verified passes, not through one perfect draft. | AI Prompt Debugging: Fixing Issues Through Iteration |
| test cases | A set of 3-5 representative inputs — clear cases, mixed cases, and edge cases — that you re-run after every prompt change to check whether it actually improved. | AI Prompt Debugging: Fixing Issues Through Iteration |
| prompt versions | Prompts managed the way code is: each version logged with what changed and what it produced, so you can compare and roll back. | AI Prompt Debugging: Fixing Issues Through Iteration |
| A/B test | Keeping two prompt versions, running each one about 10 times, and comparing success rates so data decides which is better. | AI Prompt Debugging: Fixing Issues Through Iteration |
| success rate | The share of your test cases that produce output matching expectations. It turns 'this prompt feels better' into a number you can compare across versions. | AI Prompt Debugging: Fixing Issues Through Iteration |
| unstable format | A failure mode where the same prompt produces a different output shape on each run — JSON one time, prose the next, capitalization drifting between them. | AI Prompt Debugging: Fixing Issues Through Iteration |
| lead-in | The introductory filler a model adds before the content you asked for — 'Here are the key points:', 'Here's the email:' — which has to be stripped when you want clean output. | OpenAI Prompt Engineering Best Practices |
| good-enough bar | The practical stopping rule for prompt tuning: around 90% success on your test cases, a stable format, and every part of the prompt doing something you can explain. | AI Prompt Debugging: Fixing Issues Through Iteration |
| code-generation prompt | A prompt asking the AI to write runnable code. A good one covers six things: language and version, function signature, core logic, edge cases, code style, and dependency limits. | Prompt Engineering for Code Generation |
| function signature | The function's name, its input parameter types, and its return type — the interface contract a code-generation prompt should state up front. | Prompt Engineering for Code Generation |
| special cases | The specific input conditions you tell the model how to handle: empty list, None value, duplicate entry, missing field. | Prompt Engineering for Code Generation |
| code style | The formatting, naming, commenting, and typing conventions the generated code should follow, stated in the prompt rather than left to the model. | Prompt Engineering for Code Generation |
| dependency limits | The rule stating which libraries the generated code may use — standard library only, or a named allowlist of third-party packages. | Prompt Engineering for Code Generation |
| standard library | The modules a language ships with, requiring no installation. Restricting generated code to it keeps the result portable and dependency-free. | Prompt Engineering for Code Generation |
| type hints | Explicit type annotations on parameters and return values that make the interface contract visible in the code itself. | Prompt Engineering for Code Generation |
| error handling | The code's logic for invalid input, exceptions, and edge conditions — something to specify in the prompt, not to bolt on afterwards. | Prompt Engineering for Code Generation |
| defensive programming | Writing code on the assumption that input may be invalid, deciding up front how to respond to bad data rather than trusting the caller. | Prompt Engineering for Code Generation |
| docstring | The documentation block inside a function describing what it does, how to use it, and any relevant characteristics — a code-style requirement worth stating explicitly. | Prompt Engineering for Code Generation |
| document writing | Prompt work aimed at producing or reshaping prose — technical docs, meeting notes, summaries, reports — where audience, purpose, tone, and structure carry the task. | Anthropic Prompt Engineering Overview |
| Target audience | The intended reader of a document, described by role, background knowledge, and reading goal — not just by job title. | Anthropic Prompt Engineering Overview |
| structure template | A predefined organization for the output — background, options compared, recommendation, risks — given so the model fills a fixed shape instead of choosing one. | Anthropic Prompt Engineering Overview |
| Tone and style | The register of the writing — formal or casual, detailed or terse, practical or promotional — specified so the document sounds the way the situation calls for. | Anthropic Prompt Engineering Overview |
| data-extraction prompt | A prompt that pulls structured information out of unstructured text. A reliable one spells out four things: field definitions, missing-value handling, output format, and data validation. | Prompt Engineering Guide - Few-Shot Prompting |
| field definitions | The stated meaning, type, and allowed values of each field you want extracted — for example sentiment must be exactly one of positive, negative, or neutral. | Prompt Engineering Guide - Few-Shot Prompting |
| missing-value handling | The explicit rule for what to output when a field isn't present in the source — null, 'not provided', or 'TBD' — plus an instruction not to guess. | Prompt Engineering Guide - Few-Shot Prompting |
| data validation | Rules checking that extracted data has the expected shape and range — a salary field must contain a number, a location can be a value or null but never an empty string. | Prompt Engineering Guide - Few-Shot Prompting |
| hallucination | The model's habit of confidently fabricating facts — inventing information that reads as plausible but isn't in the source and isn't true. | IBM Prompt Engineering Guide 2026 |