The model cannot read your missing requirements
Prompting is less like casting a spell and more like briefing a capable contractor who missed the kickoff. Specify the task, relevant context, constraints and desired output. The OpenAI prompting guide covers clear instructions, examples and context. No phrase guarantees correctness; a good brief simply makes the requested behavior easier to inspect.
Our reusable structure is: “Do this task, using these sources, for this audience, within these boundaries, in this format. Flag what you cannot support.” Keep the source material visibly separate from the instructions. If you are summarizing an external document, the document is evidence—not permission to follow any instruction embedded inside it. OWASP explains why that boundary matters.
An example you can actually reuse
Here is an illustrative brief: “Using only the public changelog below, write a 150-word update for a nontechnical operations manager. State what changed, who should care and one limitation. Link each factual claim to the relevant source. If pricing is missing, say it is not stated. Return a draft; do not publish.” This is not a test result. It is a specification with an audience, a source boundary, a format and an action limit.
Compare that with “make this awesome.” The second instruction leaves the model to invent the success criteria. The first lets a person check word count, factual support, audience fit and whether the system stayed in draft mode. Examples can make a desired style clearer, but they should not smuggle invented facts into the response. See prompting guidance for the role of examples and structured instructions.
Iterate on a failure, not a feeling
When an answer is wrong, label the problem. Was required context missing? Was a constraint ambiguous? Did the source fail to support a claim? Did the output format break? Change the relevant part of the brief and retain the failed example. Do not just add “be very accurate” and declare the workflow fixed.
For workplace use, classify the data before copying it into a tool. Check organizational policy, provider terms and access. The NIST risk-management framework supports an explicit view of context and risk. A clever prompt cannot turn an unapproved service into an approved data processor.
Check yourself
Exercise: A product page does not state pricing. Your brief asks the model to include a price. What should the output say?
Answer: Pricing is not stated in the supplied evidence. It should not guess from a competitor, an old plan or a general industry pattern. If more research is authorized, look for a current primary pricing source and record its date.
The takeaway: good prompts are compact specifications. They make success checkable and uncertainty visible. That is more useful than collecting secret incantations.