A prompt engineering workflow is a repeatable loop for writing, testing and improving the instructions you give a language model so it consistently returns the output you need. The steps: define what success means, write a first draft, structure it, add examples or constraints, test it on real inputs, and version the result like code.
OpenAI's prompt engineering guide defines it as "the process of writing effective instructions for a model, such that it consistently generates content that meets your requirements." Google's prompting strategies uses the term prompt design for "the process of creating prompts, or natural language requests, that elicit accurate, high quality responses from a language model."
This page walks through that workflow step by step and points to deeper pages for each technique. If you want a technique-by-technique reference with a vendor comparison table, see the prompt engineering guide. Vendor guidance here was checked against official docs on 27 October 2026.
What do you need before you write a prompt?
A definition of success and a way to measure it. Anthropic's prompt engineering overview says its guide assumes you already have:
- A clear definition of the success criteria for your use case
- Some ways to empirically test against those criteria
- A first draft prompt you want to improve
In practice this means a small set of real inputs and a written note of what a correct output looks like for each. As a rough suggestion (not a vendor figure), 10 to 30 inputs is enough to start. It can be as simple as a spreadsheet. The point is that every later change gets judged against the same inputs, not against your memory of the last run. For a deeper look at building that test set, see LLM evals.
Anthropic also warns that not every problem is a prompt problem: "Not every success criterion or failing eval is best solved by prompt engineering. For example, you can sometimes improve latency and cost more easily by choosing a different model."
How do you write the first draft?
Write it the way you would brief a capable colleague who has never seen your project. Anthropic's prompting best practices say: "Think of Claude as a brilliant but new employee who lacks context on your norms and workflows." Its key test is to show the prompt to a colleague with little context and ask them to follow it: "If they'd be confused, Claude will be too."
A useful first draft covers four things:
- The task, stated directly, including what done looks like.
- The context and the reason behind constraints. Anthropic shows that "NEVER use ellipses" works less well than explaining that the response will be read aloud by a text-to-speech engine that cannot pronounce them, because the model can generalize from the reason.
- Constraints, such as length, tone, what to avoid and what to do when information is missing.
- The output format, described precisely or enforced with a schema.
Most of these instructions belong in a system or developer message. See what is a system prompt for how that message differs from the user turn.
How should you structure a longer prompt?
Separate the parts so the model can tell instructions from data. Anthropic recommends XML tags: "Wrapping each type of content in its own tag (for example, <instructions>, <context>, <input>) reduces misinterpretation." OpenAI suggests Markdown headings plus XML tags, and lays out a common order for a developer message: Identity, Instructions, Examples, then Context.
# Identity
You review pull request descriptions for a backend team.
# Instructions
- Flag missing test plans and missing migration notes.
- Reply with a bulleted list, at most 5 items.
- If the description is fine, reply "No issues."
# Examples
<example>...</example>
# Context
<pr_description>
{{pr_description}}
</pr_description>
Two placement rules are worth knowing. OpenAI says context "is usually best positioned near the end of your prompt," and that content you reuse on every request should go at the beginning so you benefit from prompt caching. For long documents, Google's Gemini 3 guidance says to "supply all the context first" and place your specific question "at the very end of the prompt." For more on what goes into the model's window beyond the prompt itself, see context engineering.
When should you add examples, reasoning or a schema?
Add each one when your tests show a specific gap, not by default.
| Problem you see in testing | Technique to try | Deeper page |
|---|---|---|
| Output format or tone drifts | Add 3 to 5 examples | Few-shot prompting |
| Wrong answers on multi-step problems | Turn on or raise thinking, or ask for reasoning on non-reasoning models | Chain of thought prompting |
| Output breaks your parser | Enforce a JSON Schema | Structured outputs |
| One prompt is doing too many jobs | Split the task into steps | Prompt chaining |
| Task works with no examples at all | Keep it zero-shot | Zero-shot prompting |
On examples, Anthropic says they "are one of the most reliable ways to steer Claude's output format, tone, and structure" and recommends three to five. On reasoning, OpenAI's guide frames the difference between model types this way: "A reasoning model is like a senior co-worker. You can give them a goal to achieve and trust them to work out the details," while "A GPT model is like a junior coworker. They'll perform best with explicit instructions to create a specific output." So the right amount of detail depends on the model you call.
How do you test and iterate on a prompt?
Change one thing at a time, rerun your saved inputs, and compare. Google's guide notes that "Prompt engineering is iterative" and lists three moves to try when a prompt is not working:
- Use different phrasing. Different wording often yields different responses even when it means the same thing.
- Switch to an analogous task. Its example turns an open "which category" question into a multiple choice question so the model stays within the allowed options.
- Change the order of prompt content. Try moving examples, context and input around.
Keep a short log of what you changed and what happened. When a change helps on some inputs and hurts others, that is usually a sign the prompt is doing too much, and splitting it into a prompt chain can help. Anthropic says explicit chaining "is still useful when you need to inspect intermediate outputs or enforce a specific pipeline structure."
How do you keep prompts working when models change?
Pin the model and keep tests around. OpenAI notes that "Even different snapshots of models within the same family could produce different results," and strongly recommends "Pinning your production applications to specific model snapshots" and "Building tests and evaluation suites that measure prompt behavior so you can monitor performance as you iterate, or when you change and upgrade model versions."
Rerun your test set whenever you upgrade. Anthropic publishes model-specific prompting notes for its newest models and says that where a technique names a specific model, you should "treat it as measured on that model and re-check it against your own evals before applying it to another."
Where should prompts live?
In version control, reviewed like code. OpenAI's guide now says: "Store production prompts in your application code instead of creating reusable prompt objects." It is deprecating reusable prompt objects in the API, and says v1/prompts "is scheduled to shut down on November 30, 2026." Its advice for new work includes keeping prompt builders "in a small module near the feature they support" and adding "representative fixtures, tests, and evaluation checks before changing production prompts."
For prompts you use by hand rather than from an app, the same idea applies at a smaller scale. Kipt keeps prompts as Markdown files in a private GitHub repo you own, with {{name:default}} blanks for the parts that change, so the version that passed your tests is the one you reuse. Collections such as prompt templates are a starting point you can adapt and save.
What should you read next?
Start with the technique your tests point to: few-shot prompting for format drift, chain of thought prompting for reasoning, and structured outputs for parseable results. If you are building agents, AI guardrails covers the checks that sit around a prompt, and context engineering covers what the model sees beyond it.