Prompting Fundamentals

This is Unit Three of Generative AI at Work, on the fundamentals of prompting. Unit Two named the risks. This unit turns to the part of the work you control most directly: the prompt. It draws on the DAIR.AI Prompt Engineering Guide, cross-checked against vendor guidance, and on the M-CaReM-AI method's prompt patterns. Carry one question through this unit: why does the same tool give one person a useful answer and another a useless one? The answer arrives with a prompt improved twice, against written criteria. By the end you will be able to name the four elements of a prompt. To explain roles, zero-shot and few-shot prompting. To apply the guide's writing tips. To build a prompt from its elements and the method's skeleton. And to improve a prompt by testing it.

Seven entries on what a prompt is and the four elements it can hold.

What counts as a prompt.

GAI 051 What a Prompt Is

A prompt is everything you give a generative AI tool: an instruction or question, often with context, input material or examples. The DAIR.AI prompting guide notes that simple prompts can do a lot, but quality depends on the information given and how well the prompt is written. The tool fills any gap in the prompt with a guess.

Designing a prompt on purpose.

GAI 052 Prompt Design

Prompt design, which the DAIR.AI guide calls prompt engineering, is writing prompts that instruct a model to perform the task you actually want. In the guide's opening example, a bare sentence fragment gets an ordinary continuation, while adding an instruction to complete the sentence gets the task done. Design means instruction, not clever wording.

The first element.

GAI 053 Instruction

The instruction, the first of four prompt elements in the guide, is the specific task you want performed, such as summarize this complaint for the service manager, rather than pasting the complaint with no request at all. Without an instruction the model infers a task, and its inference may not be yours.

The second element.

GAI 054 Context

Context is external information or background that steers the model toward a better response, such as noting that the manager handles refunds and needs the account history, not the complaint's tone. Relevant context helps; the guide warns that unnecessary detail does not, and prompts have length limits.

The third element.

GAI 055 Input Data

Input data is the material or question you want a response about: the complaint itself, the report, the clause to rewrite, pasted below the instruction. Paraphrasing the input yourself adds your errors before the model adds its own, so give it the real text where policy allows.

The fourth element.

GAI 056 Output Indicator

The output indicator states the type or format of the output you want, such as three bullet points, then one recommended action, under one hundred words. Without a stated format, every answer arrives in a different shape, which makes results hard to compare or reuse.

When an element can go.

GAI 057 Not Every Prompt Needs All Four

The guide is explicit that a prompt does not need all four elements; which ones belong depends on the task. A sorting request can be an instruction, the text to sort and the label to return, with no context at all. Leave an element out on purpose, not by accident, and check what the tool assumed instead.

Four entries on roles in chat tools, prompting with and without examples, and what the model learns from them.

Roles in chat tools.

GAI 058 Roles in a Chat Tool

Chat tools usually separate messages into roles: a system message that sets the assistant's overall behaviour, and user and assistant messages that carry the conversation. The guide notes the system message is optional but helps, for example asking for answers as a careful policy analyst. A role sets tone and approach; it does not give the model expertise it lacks.

Asking without examples.

GAI 059 Zero-Shot

A zero-shot prompt asks for the task directly, with no examples of a good answer, such as classify this email as billing, technical or other. The guide notes that zero-shot works only as well as the model already knows the task; unfamiliar or exacting tasks need more.

Asking with examples.

GAI 060 Few-Shot

A few-shot prompt gives a handful of worked examples before the real request, such as three emails already labelled billing, technical or other, then the new one with its label blank. The examples teach the format and the decision, and a mislabelled example teaches the mistake.

What the model learns from examples.

GAI 061 Learning From the Prompt

The guide calls the effect of few-shot examples in-context learning: the model picks up a task from demonstrations inside the prompt. The same model can label emails your way in one conversation and its own way in the next, once the examples are gone. In-context learning lasts only as long as the context; it does not retrain the model.

Five entries on the DAIR.AI guide's practical tips for writing prompts.

Where to begin.

GAI 062 Start Simple

The guide's first tip is to start simple: prompting is iterative, and elements are added as results show what is missing, beginning with the instruction and input and adding context once gaps appear. A long first prompt makes it hard to tell which part helped and which hurt.

Verbs that work.

GAI 063 Command Words

Clear commands make clear instructions; the guide recommends verbs such as write, classify, summarize, translate and order. Summarize the attached minutes works better than thoughts on these minutes. A vague verb such as look at or help with leaves the task undefined, so the model picks one for you.

Where the instruction goes.

GAI 064 Instructions First, Separated

The guide reports a common recommendation: put the instruction at the beginning and separate it from the material with a clear marker, such as the instruction on top, a line of symbols, then the pasted report. When instructions and material run together, the model can mistake part of the material for an instruction.

Specific beats vague.

GAI 065 Specific Beats Vague

The guide's advice is to be specific and direct: say exactly what you want, for whom and in what form. It contrasts keep it short with use two to three sentences to explain this to a high school student. Specific does not mean long; every detail should earn its place.

Phrasing instructions positively.

GAI 066 Say What to Do

The guide advises saying what to do rather than what not to do, because positive instructions pull the model toward the details that matter: recommend from these three approved suppliers, rather than do not recommend unapproved ones. Hard limits still belong in the prompt; state them as the allowed range.

Eight entries on building, testing and keeping prompts, ending with one prompt improved twice. The opening question is answered here.

Building a prompt, element by element.

GAI 067 Building a Prompt From Its Elements

A work prompt can be built in four steps, one per element. Write the instruction first, with a clear command verb. Add the context the model cannot know: who the output is for and what they will do with it. Paste the real input material below a clear separator. State the output format, including what to do when the material holds no answer. A complete prompt still produces a draft, not a verified answer, so the checking stage applies every time.

Using examples to fix a format.

GAI 068 Showing the Format With Examples

When the output's shape matters, the guide finds examples very effective. Decide the exact format field by field. Write two or three short examples that follow it exactly, using made-up or approved sample data. Make them differ in content, so the model learns the format and does not copy the content. Put the real request last, in the same layout, with the answer blank. The model copies examples closely, mistakes and all, so check them as carefully as the output.

Splitting a big task.

GAI 069 Splitting a Big Task

The guide advises breaking a big task into simpler subtasks. List the parts, such as extracting key facts, drafting a summary, then checking it against the facts. Write one prompt per part. Run them in order, reading each result before passing it on. Then assemble the final product yourself from the checked parts. Splitting makes each step checkable; an error passed along unread spreads through every later step.

The M-CaReM-AI method's skeleton.

GAI 070 The Method's Prompt Skeleton

The method's prompt patterns share one skeleton that adds grounding and review to the basic elements. A role line says what the assistant is helping with. The real context is pasted in. The task is stated as a command. A template fixes the output's structure. Constraints follow, such as use only what is provided or plainly implied. An instruction says to record anything unclear as an open question rather than guess. And a closing reminder says the result is reviewed and corrected by hand. The constraint and the unclear-items line are the parts most often dropped, and the most important to keep.

Deciding what good looks like.

GAI 071 Define "Good" Before You Iterate

The vendor guides that agree with DAIR.AI add one step before iterating: decide what a good output looks like, then test against it. Write the success criteria: what must be included and must not appear, the format and the length. Collect a few real test cases, including an awkward one. Run the prompt on all of them and score each output. Change the prompt only where the scores show a failure. Without criteria, iteration chases whatever looks best on the day.

One change at a time.

GAI 072 Changing One Thing at a Time

Because prompting is experimentation, this course adds a working rule: change one part at a time, so you know what made the difference. Keep the current prompt and outputs as the baseline. Change a single element and nothing else. Rerun the same test cases and compare against the criteria. Keep the change if it helped and undo it if it did not. Outputs vary even when nothing changes, so judge across several cases, never one run.

Keeping what works.

GAI 073 Keeping the Version That Worked

A tested prompt is a working asset, and the M-CaReM-AI method recommends a small, living library of templates with examples of what went in and came out. Save a passing prompt with a name, a date and its task. Store a before and after example with it. Keep the library where the team already works. Retest saved prompts when the tool or task changes, because an update can change how the same prompt behaves.

One prompt, improved twice.

GAI 074 A Prompt Improved Twice

A worked example, constructed for this course, follows a facilities coordinator turning maintenance requests into a weekly report. Her first prompt, summarize these requests, gives readable but unusable output. She writes criteria first: every request listed with building and room, sorted by urgency, safety flagged, nothing invented, and keeps three past weeks as test cases. Round one adds the elements, and two weeks pass. The third fails: where a request gives no room number, the model invents one. Round two adds only the method's grounding, use what the requests state and mark anything missing as not stated, and all three weeks pass. That answers this unit's question: the difference between a useful and a useless answer is a prompt built from its elements and tested against criteria.

Look at what you can now do. You can name the four elements of a prompt, instruction, context, input and output format, and leave one out on purpose. You can explain roles, zero-shot and few-shot prompting, and why examples teach only for the conversation. You can apply the guide's tips: start simple, use command verbs, put the instruction first, be specific, and say what to do. You can build a prompt from its elements and from the method's seven-part skeleton. And you can improve a prompt against criteria, one change at a time. Unit Four turns to safe patterns for common work.