Practical Tools Hub

Start with the job you want done

OpenAI’s current Help Center guidance recommends clear, specific prompts. It emphasizes identifying the task, providing necessary context, and stating the preferred tone and style. This is a useful starting point because many weak prompts fail before wording becomes sophisticated: the model has not been told what success looks like.

A prompt does not need special jargon to be effective. It needs enough information to distinguish the desired task from nearby tasks the model could reasonably perform.

The improved version does several things at once: it defines the audience, narrows the subject, specifies required coverage, sets a length range, and removes an unwanted task. None of those instructions require “prompt engineering” terminology.

A practical prompt anatomy

Not every prompt needs every field. A simple task can stay simple. The point is to add the information that materially changes the result, not to inflate a request with ceremonial instructions.

Example 1: improve a summarization request

The key improvement is not simply “be detailed.” The prompt identifies what information must survive compression. That makes it easier to judge whether the output is useful.

Example 2: improve a coding request

This version preserves constraints that matter in software maintenance. Without them, a model might solve the immediate error by restructuring the program, changing its interface, or introducing a package the user cannot install.

Example 3: improve a decision-support request

The improved prompt supplies the decision criteria and operating context. “Best” becomes a conditional recommendation instead of a popularity contest.

Right-size complex requests

OpenAI’s guidance also recommends right-sizing and prioritizing requests. If a task contains many independent deliverables, breaking it into focused stages can make the workflow easier to inspect and correct.

For example, a research task can be divided into source collection, evidence extraction, synthesis, and final writing. That separation makes it easier to detect a weak source before it propagates into the final answer.

Iterate on the answer, not just the wording

OpenAI’s current prompting guidance treats interaction as iterative. If the first result is close but not correct, identify the specific defect. “Try again” contains little diagnostic information. “Keep the structure, but shorten the introduction, preserve the three numerical assumptions, and replace the generic conclusion with an implementation checklist” is more actionable.

Iteration is especially useful when the desired output is partly subjective. Tone, organization, degree of detail, and example selection are easier to refine after seeing a first draft.

Examples can clarify an unfamiliar output format

If the requested structure is unusual, one small example can be more precise than a paragraph describing the format. For instance, if every output item must contain a risk, evidence statement, and mitigation, showing one correctly structured item makes the pattern concrete.

The example should demonstrate the format without accidentally becoming the only content the model considers. When necessary, say that the example illustrates structure rather than supplying the complete answer.

Do not over-constrain a prompt

More instructions are not automatically better. Requirements can conflict, duplicate one another, or constrain the output so tightly that the model spends effort satisfying format instead of solving the task.

A useful test is to ask whether each instruction would change a competent human’s response. If removing a sentence would not affect the intended output, it may be unnecessary. If two instructions contradict each other, resolve the conflict rather than hoping the model will infer which one matters more.

Separate evidence rules from writing style

For factual work, it helps to distinguish what the answer may claim from how it should sound. A prompt can require that factual claims come only from supplied sources, that missing evidence be labeled, and that quotations remain exact. Separately, it can request a concise or conversational writing style.

This separation is particularly useful for research, policy, technical, legal, medical, and financial contexts because a fluent tone should never be mistaken for evidence quality.

Prompting does not guarantee correctness

A well-specified prompt can reduce ambiguity, but it cannot turn an uncertain source into a verified fact or guarantee that a model will never make an error. Consequential claims should be checked against the underlying source, calculation, code execution, or authoritative record.

That is why “cite the source” and “verify the result” are different instructions. A citation can be present and still fail to support the claim. Verification asks whether the evidence actually matches the statement.

A reusable checklist

1. State the task in one direct sentence.
2. Add only the context that changes the answer.
3. Name the audience if it affects vocabulary or assumptions.
4. Specify required sections or output format when structure matters.
5. State hard constraints and explicit exclusions.
6. Provide examples when the format is unusual or easy to misunderstand.
7. Ask for uncertainty or missing evidence to be surfaced rather than hidden.
8. For complex work, split research, reasoning, execution, and review into stages.
9. Review the first output and give targeted correction instructions.
10. Verify consequential facts independently.

Use the related tool

Open tool →

Authoritative references

• OpenAI Help Center: How do I create a good prompt for an AI model?
• OpenAI Help Center: Prompt engineering best practices