Prompt engineering patterns

The same model gives a chatty paragraph or a clean, parseable answer depending on how you build the prompt. See the parts of a good prompt go in one by one, and what each part changes.

9 min Free

When a person reads “classify this message”, they ask what the categories are and what form the answer should take. A model can’t ask. It fills the gaps with its best guess, and its guess is usually a friendly paragraph written for a human.

Prompt engineering means building the prompt so there are no gaps to fill. A prompt for an app usually has four parts:

  • A system instruction with the role (who the model is), numbered steps (what to do, in order) and the output format.
  • Few-shot examples: two or three worked examples of input and the exact answer you want.
  • Context: any documents or data the model needs.
  • The task itself, placed last.

The running example is a support inbox for a UPI payments app. Each message needs a category so it can go to the right team. Press Play to see a one-line prompt, then switch the Try it selector to the structured version and watch the same message come back in a form your code can use.

  1. Build the prompt
  2. Generate
  3. Parse
  4. Result
Your appsupport inboxSystem instr.role, steps, formatExamplesfew-shotGeminigemini-3.8-flashYour parserexpects category:Team queuerouted ticket

Press Play to watch it run, or step through with ← →.

00/06
from google import genai

client = genai.Client()

# A zero-shot prompt: no role, no rules, no examples, no output format.
interaction = client.interactions.create(
    model="gemini-3.8-flash",
    input="Classify this support message: I paid Rs 450 for a recharge, "
    "it failed, where is my money?",
)

print(interaction.output_text)

What your app received

Nothing yet. Press Play.

What to notice

  1. The model wasn’t wrong the first time. It answered the question it was given. The bare prompt never listed the categories or said what to return, so the answer was written for a person, not for your parser.
  2. The system instruction carries the rules that never change. Gemini’s prompting guide recommends putting the role, key constraints and output format in the system instruction (the system_instruction parameter), or at the very start of the prompt.
  3. Examples do more than instructions. Google’s guide recommends always including few-shot examples, and says clear examples can even replace some instructions. Keep every example in exactly the same format, because the model copies the pattern, labels and spacing included.
  4. Structure and order matter. Separate the parts with XML-style tags (<role>, <task>) or Markdown headings, and pick one style. With long context, put the context first and the question at the end.
  5. “Step by step” means steps for the task. Gemini 2.5 and 3 models already think internally before they answer, so you don’t need to ask them to show their reasoning. Numbered steps in the instruction are about your procedure: read, pick a category, write a reply.
PatternWhat it fixes
Role in the system instructionThe model doesn’t know who it is meant to be
Clear constraints (“exactly one of …”)Vague or ambiguous terms
Few-shot examplesWrong format, phrasing or length
Tags or headingsInstructions mixed up with data
Context first, task lastThe question gets lost in a long prompt
Break into smaller promptsOne prompt trying to do too much

When the format really matters
A prompt can ask for a format, but it can’t force one. When your code must parse the answer every time, use structured output, the next lesson: Structured output.

Check your understanding

1. The bare prompt returned three helpful paragraphs and no category. What is the best first fix?
2. Why must every few-shot example use the same layout?
3. You are passing a 20-page policy document plus a question. Where should the question go?