A prompt works best written like a short contract

Start here

A vague prompt produces a vague answer, and the fix documented by three major vendors is not a magic phrase but a structure. Their own prompting guides describe a similar shape for a working prompt: state what you want, give the model what it needs to work with, say what it must not do, specify the shape of the answer, and say how the result will be checked. Treating a prompt as a short contract, not a wish, is the practical version of that shape.

What the documents say

Google's Gemini API documentation recommends clear and specific instructions, explicit constraints on what the model should and should not do, added context the model 'needs to solve a problem,' and few-shot examples to 'regulate the formatting, phrasing, scoping' of the answer. Anthropic's prompting reference groups its techniques under clarity and examples, structured tags, giving the model a role, and letting it reason before answering, framed as general craft across its current model lineup. OpenAI's developer guide organizes a prompt into an explicit hierarchy of 'Identity, Instructions, Examples, and Context sections, usually in this order,' plus a caution to pin any production integration to a specific model version so behavior does not drift silently. None of the three guides claims one formula guarantees a good answer; each frames its techniques as things to test against your own examples, not settings to fix once.

Check this

This is an editorial template drawn from the three guides above. Write five short lines before sending a prompt: Goal, what you want in one sentence; Input, the material the model has to work with; Constraints, what it must not do or include; Format, the shape of the answer — length, structure, tone; and Check, how the result will be verified, such as a quote-back of the source material used. Treat a missing line as missing information, not something the model will guess correctly.

What holds and what fails

This structure holds for tasks with a checkable goal: drafting to a spec, extracting information, following a format. It holds less well for open-ended or exploratory tasks, where fixing constraints too early can foreclose the useful answers the vendors' own example and role techniques are meant to surface. This is an editorial synthesis of three separate documents, not one vendor's official recommendation, and a template built from one model's guide may need adjusting for another.

• Write Goal, Input, Constraints, Format and Check before your next long prompt.
• Add one example of the output wanted, since all three guides recommend it.
• Name how the result will be checked before asking for it.

A contract works because both sides know the terms in advance; a prompt written the same way tends to need fewer retries.