The practical prompt engineering guide.
Everything here transfers: it applies whether you are writing for a chat assistant, an image model or a coding agent. Tool-specific detail lives in the packs.
What prompt engineering actually is
Prompt engineering is the practice of writing inputs that reliably produce the output you need. Reliably is the operative word: anyone can get a decent answer once. The skill is getting a good one on the tenth run, with different input, without babysitting it.
Google Cloud frames it as designing inputs that guide a model toward a desired result, and the overview on cloud.google.com is a good non-technical starting point. The OpenAI prompt engineering guide covers the API side: how message roles are weighted, where instructions belong, and how reasoning and structured-output settings change results. Read both. Content was rephrased here for compliance with licensing restrictions.
In practice the job is specification, not incantation. You describe an outcome, the constraints it must satisfy, and how it will be judged — the same work as briefing a freelancer, except this one never asks a clarifying question unless you invite it to.
The universal seven parts
Different media emphasise different parts. Image prompts lean on description and constraints; agent prompts lean on verification and scope. The skeleton holds.
Role and audience
Whose expertise produces this, and who consumes it.
One task
A single deliverable, expressed with one verb.
Context
Text, data, code, screenshots, brand facts. Paste it rather than referencing it.
Constraints
Length, format, tone, exclusions, technical limits.
Output contract
The exact shape you want back, ideally demonstrated.
Uncertainty rule
What to do when the answer is not in the material.
Scope fence
What to leave alone, once a model can change things.
Fast diagnostic: read your prompt as a competent stranger. Every question you would need to ask is a gap the model fills by guessing.
Ten techniques cover almost everything
Anything beyond this list is usually one of these with a new name attached.
| Technique | What it is | When it earns its keep |
|---|---|---|
| Zero-shot | A clear instruction with no examples. | Simple, well-defined tasks where the format is obvious. |
| Few-shot | One to three input-output examples. | Fixing format drift and matching a specific voice or schema. |
| Step-by-step | Ask for the working before the answer. | Debugging, maths, planning — anywhere a wrong middle step ruins the result. |
| Role framing | Name the expertise and the audience. | Setting depth and vocabulary. Helps a little; context helps more. |
| Delimiters | Wrap material in fences or XML tags. | Stopping the model from confusing your material with your instructions. |
| Output contract | Specify schema, fields, length, format. | Anything a machine or a template will consume. |
| Decomposition | Split a job into sequential prompts. | Multi-part deliverables: outline, then draft, then edit. |
| Self-critique | Ask for a critique, then a revision. | Raising quality without rewriting it yourself. |
| Grounding | Restrict answers to supplied sources. | Reducing invented facts in document and research work. |
| Negative constraints | State what must not appear. | Recurring artefacts: filler openers, watermarks, unwanted music. |
The iteration loop
Good prompts are rarely written. They are converged on. This loop is deliberately boring, and it beats starting over every time.
Write the smallest complete prompt
Role, task, context, one constraint. Do not front-load everything you can imagine.
Diagnose, do not react
Name what is wrong in one sentence: wrong format, wrong depth, invented facts, wrong tone.
Change one thing
Add the constraint that was violated. Three changes at once teach you nothing about which worked.
Keep a fixed test input
Compare runs on the same material. For image models, fix the seed so the comparison is fair.
Save what worked
Keep prompts in a file, not in your chat history. Note what each constraint prevents.
Promote the durable parts
Move repeated rules into custom instructions, a system prompt or a project rules file.
Eight failures and their causes
| Symptom | Usual cause | Fix |
|---|---|---|
| Generic output | No specific context supplied | Paste source material, product facts and a voice sample |
| Format drifts | Format described, not demonstrated | Add one example of the exact output shape |
| Instruction ignored | Too many competing instructions | Cut the prompt down, or split it across two turns |
| Invented facts | No grounding rule or source | Provide sources, require verbatim quotes, add a "not found" fallback |
| Wrong length | Length given in vague terms | Specify words, and cap paragraph or section length |
| Right idea, wrong details | Constraints missing, not misunderstood | Add the violated constraint, keep everything else identical |
| Image misses elements | Too many subjects competing | Reduce to one subject, move key details earlier |
| Agent touched extra files | No scope fence | Add an out-of-scope list and a "report, do not fix" rule |
Before you send, and before you publish
Do this 07
- One task, one deliverable
- All source material pasted in and labelled
- Length and format stated explicitly
- An example, if format matters
- A rule for missing information
- Exclusions listed
- A scope fence, if the model can change things
Not this 06
- Publishing a statistic you did not verify
- Trusting claims about other products
- Shipping code that was read but never run
- Ignoring likeness and trademark risk in generated media
- Leaving AI presenters undisclosed
- Leaving secrets or customer data in prompt history
Asked often, answered plainly
Is prompt engineering a real skill or a temporary trick?
The durable part is specification: describing an outcome, its constraints and how it will be checked. That transfers to every model and every tool. The disposable part is vendor-specific syntax and flag lore, which changes with each release.
How long should a prompt be?
As long as the necessary context and no longer. Padding with quality words dilutes attention. If a prompt is long because it contains your source material, fine. If it is long because it repeats itself, cut it.
One big prompt or several small ones?
Several. One task per turn is more accurate and far easier to debug, because you can see which step went wrong instead of guessing which part of a compound instruction was dropped.
Do models need politeness or threats to perform?
No. Neither reliably improves output. Specificity, examples and constraints do. Politeness costs nothing, but it is not a technique.
How do I stop a model from making things up?
Supply the source material, require verbatim quotes or citations, give it an approved fallback such as "not stated in the provided documents", and ask it to mark uncertain claims. Then verify anything you intend to publish.
Read the primary documentation
Nine primary sources. Vendor docs outrank every blog post, including this one.
- What is prompt engineering? — Google Cloud cloud.google.com ↗ Plain-language overview of prompt engineering, prompt types and where it fits in a production workflow.
- Prompt engineering guide — OpenAI API docs developers.openai.com ↗ The API-side reference: message roles, instruction placement, reasoning controls and structured output.
- Prompt design strategies — Google Cloud (Vertex AI) cloud.google.com ↗ Concrete strategies for Gemini prompts: instructions, examples, constraints and context ordering.
- Prompt engineering overview — Anthropic docs.anthropic.com ↗ Claude-specific guidance: XML tags, long context handling and system prompts.
- Midjourney documentation docs.midjourney.com ↗ Official parameter list, aspect ratios, style references and version notes.
- Kiro documentation kiro.dev ↗ Specs, steering files, hooks and agent settings for the Kiro IDE.
- Google Antigravity antigravity.google ↗ Google’s agent-first development platform built around Gemini models.
- Sora — OpenAI openai.com ↗ Product page and capability notes for OpenAI’s video generation model.
- Veo video generation — Google deepmind.google ↗ Model overview for Google’s Veo text-to-video and image-to-video family.