Grown-up prompt engineering: how to write requests to OpenAI and Anthropic models so they actually work

Introduction

Over the past two years, a lot of myths have built up around prompt engineering. Some people are still hunting for “magic words”, some collect sets of clever phrasings, and some believe that with the new models prompts are no longer needed at all. Both are extremes.

If you boil OpenAI’s and Anthropic’s recommendations down to one honest idea, it goes like this: a strong prompt is not a magic phrase but a well-framed task. A good request does not make the model guess what exactly you meant. It sets the goal, context, constraints, format, quality criteria and rules for behaviour in ambiguous situations.

That is what mature prompt engineering is about. Not verbal tricks, but disciplined thinking. The model works better not because it has been “persuaded”, but because it has been given a clear contract for the result.

OpenAI’s recommendations focus on clear instructions, the order of blocks, specifics, examples, controlling the response format and the difference between prompting ordinary GPT models and reasoning models. Anthropic adds a more developed view of XML structure, long context, tool use, thinking modes, agentic systems, self-checking and long autonomous tasks. Together these approaches add up to a single working system.

Below is a detailed practical guide: the core rules, the architecture of a strong prompt, algorithms by task type, anti-patterns, error diagnostics and a set of templates you can adapt to real tasks.

1. What a strong prompt looks like in practice

A weak prompt usually only looks fine at first glance. It can be short, polite and even sound “reasonable”, but inside it almost always lacks critically important things. The model does not understand what result counts as good, where the context ends and the instruction begins, whether it can make assumptions, how strictly to follow the format, and whether it should explain its working or go straight to the final result.

A strong prompt, by contrast, removes uncertainty. It works like a good brief for a strong contractor: it sets the goal, the boundaries, the expected type of result, the constraints and the acceptance criteria.

The easiest way to remember this is a formula:

strong prompt = role + goal + context + input data + constraints + response format + examples + quality check.

Not every request needs all the elements to the same degree, but together they form the basis of almost any well-framed task.

2. The main rules of prompt engineering

First you define the result, not the wording of the request

The main beginner’s mistake is to start with a phrase rather than an outcome. Before writing a prompt, it helps to answer a few questions for yourself: what exactly should come out at the end, by what criteria will I know the result is good, which constraints are mandatory and what is unacceptable.

The request “write a good piece about product thinking” is too weak not because it is short, but because it defines almost nothing. Who is the audience? What is the thesis? How long? What style? Do you need an article, key points, a post, a speech, a note for a channel, presentation copy? Can lists be used? Are examples needed?

Before writing a request, you need to answer four questions:

1. What exactly should come out at the end?
2. How will I know the result is good?
3. Which constraints are mandatory?
4. What is unacceptable?

For example, a poor task statement:

Write a good piece about product thinking.

A good task statement:

Write a 6–8 paragraph article for an audience of founders and product managers. Explain why, in the age of AI, the speed of building a product has stopped being an advantage in itself. Show that the key question is not “what can we build” but “what problem is the customer willing to pay to solve”. Style: smart, clear, no bureaucratese. No lists, apart from one short block of 3 questions. No links.

In the second version, the model understands:

— the topic;

— the audience;

— the thesis;

— the length;

— the style;

— the structure;

— the prohibitions.

A strong version of such a request already looks like a task: write a 6–8 paragraph article for founders and product managers, show why in the age of AI the speed of building a product has stopped being an advantage on its own, explain that the key question is not what can be built but what problem the customer is willing to pay to solve, and keep a clear, lively style without bureaucratese and without links. Here the model is no longer guessing; it is working.

Instructions must be kept separate from data

Both OpenAI and Anthropic state plainly that the model copes better when the prompt is structured. The most common problem is mixing the command and the material into one unmarked block. In that form the model gets worse at telling what is an instruction and what is data to be analysed.

So the prompt should be laid out in blocks. The most convenient options are:

— Markdown headings;

— XML tags;

— explicit sections such as Instruction, Context, Input, Response format.

An example in Markdown:

# Task
Write an analytical summary of the document.

# Context
The text below is an interview transcript.

# Requirements
- Fix obvious speech errors
- Do not change the meaning
- Attribute the two speakers' turns correctly

# Response format
1. A short summary
2. The full proofread version of the interview

# Input data
"""
...
"""

So a prompt almost always benefits from explicit structure. It can be Markdown with the sections “Task”, “Context”, “Requirements”, “Response format”, or it can be XML with the tags <role>, <task>, <context>, <input>, <constraints>. Anthropic is particularly consistent in promoting XML as a way to remove ambiguity in complex prompts.

Don’t write vaguely

Words like “fine”, “nice”, “not too long”, “professional”, “do it like an expert” look like instructions but in fact set almost nothing. The model does not know what exactly you mean by these phrases.

Prompts break on words like:

— “fine”;

— “nice”;

— “not too long”;

— “short but detailed”;

— “do it like a professional”.

The model does not know what exactly you mean by these words. They need to be translated into operational requirements.

Instead of:

Make it short.

Better:

The answer is 5 points, each 1–2 sentences long.

Instead of:

Write it in a lively, expert way.

Better:

Style: confident, clear, no bureaucratese, no marketing fluff. Medium-length sentences. A lively conversational tone is allowed, but without over-familiarity.

Any abstraction needs to be translated into working criteria. Not “make it short”, but “give 5 points of 1–2 sentences each”. Not “write in a lively, expert way”, but “the style is confident and clear, without bureaucratese or marketing fluff, medium-length sentences, a lively conversational tone is allowed without over-familiarity”.

The response format is set as a contract

If the format matters, it cannot be described vaguely. Don’t ask for “JSON, roughly like this”. The format needs to be set as a contract.

Poor:

Return JSON.

Better:

{
  "topic": "string",
  "key_points": ["string"],
  "risks": ["string"],
  "conclusion": "string"
}

Even better, add rules:

— no extra fields;

— no comments outside the JSON;

— if data is missing, return an empty array or a null field;

— don’t invent values.

The same principle works for texts too. “Write briefly” is worse than “answer in three paragraphs: problem, conclusion, recommendation”. The easier it is to check afterwards that the result matches the format, the more reliably the prompt works.

Examples are one of the most powerful levers

OpenAI recommends following a clear ladder: first zero-shot, then few-shot, and only if that is not enough, think about more systematic tuning. Anthropic also puts a strong emphasis on few-shot, especially when the task is ambiguous or when the exact structure, tone and type of thinking matter.

1. First, try zero-shot.
2. If quality is unstable, add few-shot.
3. If the task is repeated at scale and regularly, think about more systematic tuning or fine-tuning.

Good examples should be:

— relevant;

— diverse;

— showing exactly the pattern you need;

— separate from the instructions.

Their job is not just to show the desired answer, but to lock in the pattern the model should reproduce.

Say what to do rather than only what not to do

One of the most useful takeaways from the materials: negative prohibitions work less well than positive instructions.

Poor:

Don’t write drily. Don’t use lists. Don’t use bureaucratese. Don’t repeat the question.

Better:

Write in flowing paragraphs. Style: lively, journalistic, confident. Get straight to the point, without repeating the question. Use lists only if they genuinely improve readability.

Prohibitions are needed, but they should not be the only way of steering the model.

1.7. A good prompt takes the model’s mode into account

This is a very important point.

Different models and modes call for different kinds of steering.

For ordinary GPT models, it helps to describe the steps, format, structure and rules explicitly.

For reasoning models, what works better is:

— a clear goal;

— constraints;

— an explicit output contract;

— criteria for “what counts as done”.

But don’t spell out the model’s internal thinking in too much detail. Modern reasoning models often do better when they are given a framework rather than having every thinking operation forcibly prescribed.

1.8. Parameters are no substitute for a good prompt

Temperature, max tokens, reasoning effort and other settings are a secondary layer.

The right order is:

1. First a good prompt.
2. Then examples.
3. Then verification rules.
4. Only then parameter tuning.

Factual tasks, extraction and truthful QA usually need a low temperature.

For more creative tasks, a higher one is acceptable.

But a bad prompt cannot be “rescued” by temperature alone.

3. The architecture of a strong prompt

In practice, almost any strong prompt can be broken down into eight blocks.

1. Role

The role sets a pattern of behaviour. It doesn’t have to be long, but it often helps to narrow the mode of work. “You are an interview editor”, “You are a research analyst”, “You are an engineer who studies the code first and only then changes it”: these are not decorations but a way of shifting the model into the right mode.

2. Goal

What matters here is describing not just the action but the expected result. Not “analyse the document”, but “put together an analytical summary, pick out the key points, the contentious points and the practical conclusions”.

3. Context

Context answers the question: what does the model need to know before it starts? Who is the audience? How will the result be used? What are the premises? Why is the task being set at all? Anthropic specifically stresses that context and the motivation behind the desired behaviour can noticeably improve the quality of the answer.

4. Input data

This is the material itself: text, a table, a transcript, code, documents, a list of links, user input. It should be kept separate from the instructions.

5. Constraints

This covers style, length, how much freedom the model has, a ban on speculation, rules for what to do when data is missing, whether sources are required, restrictions on lists, links, bureaucratese, assumptions and so on.

6. Response format

The answer should be specified so that it can be checked. Even if it is free text, it helps to define the desired structure: for example, “first a short summary, then the analysis, then recommendations”.

7. Examples

Not always needed, but especially useful for formatting, extraction, text transformation, classification and style tasks.

8. Quality check

This is a critically important layer that is often forgotten. It helps to tell the model explicitly: before finishing, check that every part of the task is covered, the format is followed, there are no contradictions and no unconfirmed facts have been added. Anthropic particularly stresses the value of self-checking, and the GPT-5 guidance for coding and agentic scenarios makes verification an outright mandatory discipline.

Here is a basic skeleton you can use as a universal starting point:

<role>
You are [role].
</role>

<objective>
You need to produce [exact result].
It counts as a success if:
1. ...
2. ...
3. ...
</objective>

<context>
Here is the important context:
...
</context>

<input>
Here is the input data:
...
</input>

<constraints>
- Keep to the style: ...
- Length: ...
- Do not invent unconfirmed facts.
- If the data is insufficient, flag the uncertainty explicitly.
</constraints>

<output_format>
Return the result in the format:
...
</output_format>

<examples>
  <example>
    <input>...</input>
    <output>...</output>
  </example>
</examples>

<verification>
Before the final answer, check:
- whether every part of the task is covered;
- whether the format is followed;
- whether there are any contradictions;
- whether anything unconfirmed has been added.
</verification>

4. A basic algorithm for designing a prompt

A good prompt is almost always put together by the same logic.

First, the type of task is determined. Until it is clear whether this is generation, extraction, editing, analysis, research, code or agentic work with tools, it is hard to frame the request well.

Then you define what counts as success. The criteria literally need to be written out: are all parts of the task covered, are hypotheses acceptable, is a strict format needed, are sources needed, can the result be checked automatically.

The next step is to define how much freedom the model has. Should it simply answer, suggest options, look for data itself, act autonomously, ask for confirmation before risky actions? This part is especially important for tool use and agentic modes.

Next, the prompt is laid out in blocks: role, task, context, constraints, format, check. If the task is complex, add examples, citation rules, research mode, dependency checks, a completeness contract and a tool policy.

Then ambiguity is removed. The best test question here is very simple: if you gave this prompt to a person with no extra context, would they understand exactly what needs to be done?

After that, the prompt is tested not on one case but on several: a normal one, a hard one, an edge case, a case with missing data and a case with conflicting sources. Only then does the real refinement begin.

The main rule for fixing a prompt: what needs fixing is not the “beauty of the wording” but the weak spot in the contract. If the model gets things wrong, the cause is usually one of five: not enough context, an undefined format, no examples, no behaviour set for uncertainty, or no final check.

5. Algorithms by task type

Text generation

For texts, the most important thing is to set the audience, the goal and the main thesis correctly. If you don’t say who the reader is and what effect you want, the model will almost inevitably slide into generic writing “for everyone”. A good generation prompt sets the author’s role, the audience, the purpose of the text, the key idea, tone, style, length limits and structure rules.

Basic template:

You are a strong editor and writer.

Task: write a text on the topic [topic].
Audience: [who is reading].
Goal: [what effect it should have].
Main thesis: [what needs to get across].

Requirements:
- style: ...
- tone: ...
- length: ...
- structure: ...
- allowed / not allowed: ...

Give the answer straight away in final form, without explaining the process.

Fact extraction and classification

Here creativity should be minimal and structure as strict as possible. You need an explicit ban on speculation, an exact response schema and clear behaviour for when the necessary data is not there.

<task>Extract the entities from the text.</task>
<constraints>
- Extract only what is directly in the text.
- Do not make anything up.
- If an entity is absent, return an empty array.
</constraints>
<output_format>
{
  "companies": [],
  "people": [],
  "topics": [],
  "themes": []
}
</output_format>
<input>
...
</input>

Analysing long documents

Anthropic specifically highlights several strong practices for long-context tasks: long documents are better placed higher up in the prompt, with the request itself closer to the end; several documents should be marked up separately and accompanied by metadata; before synthesising a conclusion, it helps to ask the model to first extract the relevant quotes or facts.

This is especially important for interviews, transcripts, court documents, large reports, presentations, research and collections of documents on a single topic.

<documents>
  <document index="1">
    <source>Interview 1</source>
    <document_content>...</document_content>
  </document>
  <document index="2">
    <source>Interview 2</source>
    <document_content>...</document_content>
  </document>
</documents>

<task>
First, identify all the places where the speaker can be reliably identified.
Then put together a complete proofread version.
If you are not confident enough, flag it explicitly.
</task>

Research and deep research

For research, a general request like “study the topic and tell me about it” almost always works poorly. An explicit research mode is stronger. The model should break the topic into sub-questions, research each one separately, check for conflicting facts, repeat the search when it comes back empty, and clearly separate confirmed facts from conclusions.

<research_mode>
- Break the topic into 3–6 sub-questions.
- Research each one separately.
- If the results are empty or too narrow, try 1–2 alternative strategies.
- Finish the research only when further searching is unlikely to change the conclusion.
</research_mode>

<citation_rules>
- Cite only sources you have actually found.
- Do not invent links or quotes.
- Tie each source to a specific claim.
</citation_rules>

<grounding_rules>
- Make no claims that are not backed by data.
- If sources conflict, show the conflict explicitly.
- If something is a conclusion rather than a direct fact, flag it.
</grounding_rules>

Code and coding agents

Here OpenAI’s and Anthropic’s recommendations converge especially closely: first understand the task and the environment, don’t change code before examining the relevant part of the code, always check the result after making changes, take hidden tests and edge cases into account, and don’t finish a task on the feeling that “it seems to work”.

<role>
You are a software engineer who works carefully and checks changes thoroughly.
</role>

<workflow>
1. First understand the task and the codebase.
2. Do not edit files until you understand where the change goes and what it means.
3. After making changes, check the code with tests or by running it directly.
4. Do not finish the task until you are sure the solution is correct.
</workflow>

<verification>
- Check not only the visible cases but also edge cases.
- Do not consider a change successful just because the patch applied.
- If something could not be checked, say so honestly.
</verification>

OpenAI also mentions the trick of leading words: for Python, starting with import can help; for SQL, SELECT. It is a small but sometimes useful way of gently nudging the model towards the right generation format.

Agentic scenarios and tool use

When the model has access to tools, you need to set not only the task but also a policy for action: when to use a tool, when to carry on without it, when the result must be checked, what counts as a risky action, and in which cases to ask the user for confirmation.

<tool_policy>
- Use tools if they noticeably improve correctness, completeness or grounding.
- Do not stop early if an additional tool call could substantially strengthen the result.
- If a tool returned an empty or suspiciously narrow result, try an alternative route.
</tool_policy>

<dependency_checks>
- Before an action, check whether preliminary search, reading or data extraction steps are needed.
- Do not skip prerequisite stages just because the final action seems obvious.
</dependency_checks>

<safety>
- If the next action is irreversible or affects external systems, ask for confirmation first.
</safety>

6. What matters most for modern reasoning models

Modern reasoning models have an important feature: you often don’t need to spell out every thinking step by hand. OpenAI explicitly distinguishes between prompting GPT models and prompting reasoning models. Anthropic also stresses that overly rigid step-by-step control can even get in the way.

For a reasoning model, what works better is not hand-made CoT theatre but a clear framework: goal, constraints, format, quality criteria and a requirement for a final check. A phrasing like “solve the task carefully; before the final answer, check that it meets all the conditions” is usually more useful than trying to spell out the thinking process by hand down to the smallest detail.

Small models, by contrast, more often need stricter and more explicit instructions: the important rules at the beginning, a specific order of steps, a strictly defined output format, a description of edge cases and at least one good example.

7. Anti-patterns that break prompts

The first and most common anti-pattern is “make it good”. That is not an instruction but a hope. The model does not know what “good” means in your context.

The second is lumping the task and the input data together. When a prompt is unmarked, the model more often loses the structure and the role of the individual parts.

The third is the lack of a response format. Then each run may come out packaged differently, and the result becomes unstable.

The fourth is the lack of a rule for what to do when data is missing. In that situation the model either starts hallucinating or goes into endless clarifications.

The fifth is the lack of a completion criterion, especially in agentic tasks. The model may finish too early or, conversely, keep working endlessly with no clear stopping point.

The sixth is an excess of prohibitions without a positive framework. Negative constraints are useful, but without an explicit description of the desired behaviour they work less well.

The seventh is overcomplication for no reason. A strong prompt doesn’t have to be long. It has to be sufficient. It is better to start with the minimal structure that handles real cases, and only then build up the complexity.

8. Diagnostics: why a prompt works poorly

If the result is weak, ask yourself these questions in order.

Did the model understand the task at all?

Signs that it didn’t:

— it answers the wrong question;

— it drifts into generalities;

— it confuses the mode of work.

The fix:

— rewrite the goal;

— simplify the wording;

— separate the instruction from the context.

Did it have enough context?

Signs:

— it makes things up;

— it mixes up participants, dates, roles;

— it draws polished but unconvincing conclusions.

The fix:

— add relevant data;

— remove the noise;

— mark up the sources.

Was the format set strictly?

Signs:

— a structure that changes from run to run;

— it can’t be parsed automatically;

— each run is packaged differently.

The fix:

— set a schema;

— add an example;

— say directly: “return only this format”.

Does the model understand what to do when data is missing?

Signs:

— hallucinations;

— unnecessary clarifications;

— stopping halfway.

The fix:

— add missing-context behaviour;

— explicitly allow cautious assumptions only if they are flagged;

— for retrievable context, point it to the tools.

Is there a built-in check?

Signs:

— an answer that looks right but is incomplete;

— missed sub-points;

— format violations.

The fix:

— add a verification loop;

— add a completeness contract.

9. A set of ready-made templates

Universal template

<role>
You are [role].
</role>

<task>
Do [exact task].
</task>

<context>
Here is the important context:
...
</context>

<constraints>
- Do not make up facts.
- Keep to the style: ...
- Length: ...
- Structure: ...
</constraints>

<output_format>
Return the answer as:
...
</output_format>

<verification>
Before the final answer, check for completeness, correctness and compliance with the format.
</verification>

Template for analysing several documents

<documents>
  <document index="1">
    <source>Document 1</source>
    <document_content>...</document_content>
  </document>
  <document index="2">
    <source>Document 2</source>
    <document_content>...</document_content>
  </document>
</documents>

<task>
1. First, pick out the facts relevant to the topic.
2. Then compare the documents.
3. Then put together a single conclusion.
4. If the data conflicts, show the conflict explicitly.
</task>

<output_format>
1. Facts
2. Discrepancies
3. Overall conclusion
4. Uncertainties
</output_format>

Template for deep research

<role>
You are a research analyst.
</role>

<research_mode>
- Break the topic into 3–6 sub-questions.
- Research each one separately.
- If the search is empty or too narrow, try alternative strategies.
- Stop only when a new search is unlikely to change the conclusion.
</research_mode>

<citation_rules>
- Cite only real sources.
- Do not invent links or quotes.
- Tie each source to a specific claim.
</citation_rules>

<grounding_rules>
- Make no claims that are not backed by data.
- If something is a conclusion rather than a direct fact, flag it.
</grounding_rules>

<output_format>
1. Short answer
2. Key conclusions
3. Contentious points
4. Sources by claim
</output_format>

Template for an article

You are a strong editor and writer of long-form texts.

Task: write an article on the topic [topic].
Audience: [audience].
Goal: [purpose of the text].
Main thesis: [thesis].

Requirements:
- style: smart, clear, lively;
- no bureaucratese;
- no repetition;
- a logical structure with smooth transitions;
- length: [length];
- lists only if really needed.

Give the final text straight away.

Template for a Telegram post

Write a Telegram post.

Topic: [topic]
Audience: [who is reading]
Goal: [what the reader should do]

Requirements:
- a strong headline;
- a short, gripping opening;
- a clear explanation of the point;
- tone: lively, confident, easy to read;
- no fluff;
- length: [approximately];
- ending: [CTA or the required ending].

Template for reconstructing an interview from a transcript

<role>
You are an interview editor and transcript analyst.
</role>

<task>
Put together a complete interview from a raw transcript.
</task>

<context>
There are two speakers: [who exactly].
There may be recognition errors and mixed-up lines.
</context>

<constraints>
- Do not change the meaning.
- Fix only obvious speech and OCR/ASR errors.
- Attribute each speaker's turns as accurately as possible.
- If confidence is low, flag it explicitly.
</constraints>

<output_format>
1. Short summary
2. The complete interview
3. Unclear passages
</output_format>

10. A final checklist before launch

Before considering a prompt ready, it helps to run it through a short list.

Is it clear what exactly needs to be done? Is it clear what result counts as good? Are the instructions separated from the input data? Is there an explicit response format? Is the behaviour for missing data defined? Are examples needed? Is a self-check needed? If tools are used, is it specified when to act and when to ask for confirmation? If the task is research, are there grounding and citation rules? If the context is long, are the documents marked up?

If the answer to even a few of these questions is no, the prompt can almost certainly be made stronger.

Conclusion

The main takeaway from OpenAI’s and Anthropic’s recommendations is very pragmatic. A strong prompt is neither magic nor a collection of secret phrasings. It is a way of turning a vague human intention into a clear working task for the model.

When a prompt is well built, the model gets not just a “topic” but a clear mode of work. It knows what needs to be done, for whom, in what format, with what constraints, how to behave under uncertainty and how to check itself before the final answer.

That is why mature prompt engineering is, in essence, the architecture of task-setting. The better you are at stating the goal, setting the context, limiting freedom where it is dangerous and leaving it where it is useful, the stronger the results become.

In one sentence, it comes down to a simple formula:

don’t ask the model to “make it nice”: build it a clear contract for the result.

The prompt is only part of what the model sees. Everything else that reaches it before it answers is context, and that needs managing too.

The minimal structure of a good request

Describe the goal, the input data, the constraints, the output format and the verification criteria. If the task is repeated, save this contract as a template and add a few examples of right and wrong answers: that way quality will be more stable than if you try to “ask nicely” every time.