OpenAI Prompt Engineering Guide, Explained Plainly

Search openai prompt engineering and the top result is a guide, the second result is a different guide, and the third is a Reddit summary of a version of the first guide that has since been rewritten. That's the problem in one line. OpenAI has been publishing prompting advice since the days of """ delimiters and "leading words", and the advice has been revised, split, and layered rather than replaced, so "the OpenAI guide" now means at least four documents written for three generations of models.

Here's the plain answer. If you're using a current GPT model through the API, read the platform guide. If you're on a reasoning model, read the reasoning best practices, because two of the platform guide's habits actively hurt there. If you're on GPT-6 Astra, read its own page first, since it describes behaviours the general guide doesn't mention. And if you just want the rules of thumb, the help center article is still ranking and still good, as long as you know which of its nine rules the newer documents have quietly retired.

I read all four on the same day, plus the Microsoft page that ranks alongside them, and this is what each one says that the others don't, where they contradict each other, and one task written three times by their rules.

Four Documents, One Name

The help center piece is the oldest lineage and it's still being maintained. The archived copy I could open, from late June 2026, carries an "Updated: 2 days ago" stamp and a new ninth rule, so somebody at OpenAI is tending it. The live page returned a 403 to every fetcher I tried, which is worth knowing if you go looking.

One definition worth keeping from the platform guide, because it's the least mystical one I've seen from a vendor. "Prompt engineering is the process of writing effective instructions for a model, such that it consistently generates content that meets your requirements." Instructions, consistently, requirements. Nothing in there about magic words.

The Nine Rules And What Happened To Them

The help center's numbered list is what most people mean by the OpenAI guide, and the Reddit summary on the results page digests an earlier edition of the platform guide that taught similar rules under different headings. Here's each rule with what the newer documents did to it. The right-hand columns are my reading of the newer pages, not anything OpenAI says about the old list.

Rules 1, 3, 6, and 7 survived untouched. Rule 8, the cue at the end of the prompt that nudges the model into a pattern, is the one I'd call retired. It made sense when a model was a completion engine and a trailing import told it which language you meant. The current documents describe models that decide structure on their own, and the Astra page spends a whole section on getting the model to format less. A cue that says "start your answer like this" is solving a problem from the other direction.

Rule 4 is the interesting one, because it flipped on one model family and stayed put on the other. The reasoning best practices say to write the prompt without examples first, and if you do add them, to make sure they "align very closely with your prompt instructions", since mismatches "may produce poor results". On GPT models examples are still the fastest way to fix a format. Same rule, opposite default, depending on the model string. There's a longer version of that split in chatgpt prompt engineering, including the techniques it doesn't affect.

One Task, Written By Each Document's Rules

The task is turning a customer support thread into a status note for an account manager. It's a good test because it has a length constraint, an order constraint, a piece of information that's often missing, and a temptation to guess.

The Help Center Shape

Single prompt, instructions first, """ around the pasted material, a specific length, a "what to do instead", and an out for the missing owner. The trailing cue is rule 8, kept here because this is the document that recommends it.

Summarize the support thread below as a status note for the account manager. Use a 3 to 5 sentence paragraph. State what the customer asked for, what has been done so far, and what the next action is and who owns it. If the thread does not say who owns the next action, write "owner not stated" instead of guessing. Refer to the customer by company name only, never by an individual's name.

Thread: """
{thread}
"""

Status note:

The out, "owner not stated", is Microsoft's phrasing of a rule the help center only implies. Their page suggests including something like "respond with 'not found' if the answer isn't present", and says it helps the model avoid generating false responses. I'd put that line in every extraction prompt I write, on any model, because the alternative is a plausible name in a field that should have been blank.

The Developer Message Shape

Same specification, split into the roles the platform guide describes. The developer message carries the stable parts and the user turn carries the thread, which is also the layout that lets prompt caching match the prefix on repeat calls.

## Identity
You write status notes for account managers from customer support threads.

## Instructions
* Output one paragraph of 3 to 5 sentences and nothing else.
* Cover, in this order: what the customer asked for, what has been done so far, the next action and who owns it.
* If the thread does not name an owner for the next action, write "owner not stated". Do not infer one.
* Refer to the customer by company name only. No individual names.

## Examples
<thread_example>
Mara (Okefield Ltd): Our export job has failed twice since Tuesday. Can someone look?
Support: Reproduced it. Escalated to the data team with the job IDs.
</thread_example>
<note_example>
Okefield Ltd reported an export job failing twice since Tuesday. Support reproduced the failure and escalated it to the data team with the job IDs. The next action is the data team's investigation; owner not stated.
</note_example>

The user turn is <thread>{thread}</thread> and nothing else. The example does two jobs. It shows the paragraph shape, and it shows "owner not stated" being used correctly, so the model has seen the out exercised rather than just described.

On a reasoning model, the reasoning best practices would have you delete the Examples section first and see if the four instructions are enough. They'd also have you leave out anything like "think carefully about the thread", since the model does that internally and the page says the cue "can sometimes hinder it". And if you wanted the note in Markdown rather than plain text, the first line of the developer message would need to be Formatting re-enabled, which is one of those facts that costs an hour if you don't know it.

The Astra Shape

The Astra page describes a model that "tends to use lists, tables and Markdown to make responses scannable", "may use recurring phrases across sessions", and is "more likely to ask the user a question when additional input could materially change the result". For a status note, all three are wrong behaviours, so the developer message grows two sections.

## Writing Style
Write one plain paragraph. Do not use lists, tables, headings, or bold. Do not open with a label such as "Status note" and do not close with a summary sentence. Use familiar words and precise verbs.

## Initiative
Do not ask clarifying questions. If something the note needs is missing from the thread, say so inside the note in one clause and continue.

Those sit under the same Identity, Instructions, and Examples as before. The writing-style block is a trimmed version of the prose prompt OpenAI ships on the Astra page, and the initiative block is my answer to the questions behaviour, since a status note is a one-shot job with nobody on the other end to answer a question. OpenAI's own version of that prompt is longer and aimed at agents doing multi-step work, telling the model to "persist until the user's intended goal is complete" and to prepare a reviewable result before asking for approval.

Where The Documents Disagree

Three places, and I think each one tells you something about how the models changed.

Instructions at the start, or at the end, or both. The help center says the beginning. Microsoft's page says models "can be susceptible to recency bias", so it's worth experimenting with repeating the instructions at the end, and its best-practices list says "double down", instructions before and after the primary content. The platform guide puts context last in the developer message and says nothing about repeating. My read is that Microsoft's advice was written against models with weaker instruction following, and that on the current ones it's cheap insurance for long inputs and unnecessary for short ones. The developer-message shape above already ends with the examples, which is a soft version of repeating yourself.

Cues, or no cues. The help center's rule 8 and Microsoft's "prime the output" section both tell you to end the prompt with the first few words of the answer you want. The Astra page tells you the model formats too much on its own and hands you a prompt to make it stop. Both are true of their models. On anything current I'd drop the cue and state the format in the instructions instead, which is what the platform guide's layout does anyway.

Temperature. The help center says "for most factual use cases such as data extraction, and truthful Q&A, the temperature of 0 is best". Microsoft gives the range as 0 to 2, calls 0.2 focused and 0.7 divergent, and adds that you should "alter one of these two parameters at a time, not both", meaning temperature and top_p. The reasoning best practices and the Astra page don't mention temperature at all, which I'd take as a hint about where the control has moved. Astra exposes a reasoning effort setting instead, and its page notes the model "does not support the none reasoning effort". If you're carrying a temperature-0 habit from 2023 into a reasoning model, the honest position is that the documents no longer promise it does what it used to.

The Prompt OpenAI Wrote Against Its Own Model

The most useful thing on the Astra page, to me, is an admission. OpenAI ships a prompt whose job is to strip the model's own stock phrases. It lists specific words and openers to avoid, bans concluding summary statements, and bans what it calls contrastive framing, the "X, not Y" construction that introduces an alternative nobody asked about. It also bans invented compound labels and canned transitions.

I'm not going to reproduce the word list, partly because this site has its own version of it and partly because pasting a list of banned words into an article is a good way to fail your own rule. The point is what the list implies. The vendor has looked at what its flagship writes by default, identified the tells, and published the counter-prompt. Which means "the model wrote it" is now a style you can opt out of with a paragraph, and the paragraph is in the documentation.

If you write anything customer-facing with these models, that paragraph is the first thing I'd add to the developer message, before any role or persona. The persona changes the register. The style prompt changes whether a reader can tell.

About The PDF, GitHub, And Reddit Versions

People search for the guide as a PDF, and there isn't one. What there is, is better. Every page on the platform docs has a Markdown mirror, reached by appending .md to the URL, and the docs publish an llms.txt index of the whole set. That's how I read the guide for this article, and it's how I'd read it into a model if I wanted one to reason about the documentation, since the Markdown version is the page without the navigation.

The GitHub search mostly finds copies and summaries. The Reddit result on the page is a bullet-point digest of an earlier edition of the platform guide, and it's fine as a memory aid for that edition. It predates the reasoning models, the developer role, and the Astra page, so treat it as the 2023 shape and nothing else.

Nothing in the four documents costs money, and none of them is a course. If you want the material sequenced, the site's course reviews are linked from the chatgpt prompt engineering post above, and the general framework the OpenAI documents assume you already have, the six slots every prompt fills, is in chatgpt prompts, with the reusable templates in chat gpt prompts.

What I'd Read First

The platform guide, once, start to finish. It's the document that says pin your model snapshot and write tests before you touch a production prompt, and everything else is downstream of those two sentences.

Then the page for whichever model you're actually on. The reasoning page if the model reasons, the Astra page if it's Astra. Don't read the help center article until after that, because its nine rules are excellent for a model that no longer needs three of them, and you'll want to know which three.

And keep the specification separate from the wrapper. The status note task above didn't change across three prompts. The container did. How far that container changes when you leave OpenAI for another vendor is the subject of llm prompt engineering, and the short answer is further than you'd think.