Why layout matters
A prompt has content (what you ask for, the material, the conditions) and layout (how those parts are separated and in what order). The ten checks cover content in the first nine. The tenth, Fit, asks whether the prompt is laid out the way the target model reads best.
Each vendor publishes guidance on that. The summaries below paraphrase each vendor’s own documents as read on October 10, 2026. They are the same rules the Grader uses for its Fit test and its rewrites. Vendors revise their guidance when they release new models, so treat this as a snapshot and follow the source links for the current text.
What all three share
Before the differences, the common ground. Read side by side, the three vendors’ guidance agrees on more than it disagrees:
- State the task plainly and explicitly. Anthropic asks for the task, the output format and the constraints to be stated outright. OpenAI asks for the outcome and what success looks like. Google asks for the goal to be stated plainly.
- Separate the parts. All three recommend marking out the parts of a long prompt, with XML tags, Markdown headings or both.
- Say what shape the answer should take. Describe the format you want rather than leaving it to the model.
- Write calmly. Anthropic advises leaving out capitalized emphasis and be-thorough nudges. OpenAI advises keeping words like always, never and must for true invariants. Google advises removing persuasion, flattery and pressure.
When you do not know the model
If a prompt will run on whatever model a colleague or customer picks, write for the shared ground. The Grader’s “Any chat model” setting uses these six rules:
- Say exactly what to produce, who it is for and what it will be used for.
- Separate instructions from pasted material with plain labels and blank lines.
- Put long material before the question.
- State the length and the format wanted.
- Say what to do when information is missing or unclear.
- Give each instruction once, in plain words, with no capitals for emphasis.
Claude
Anthropic’s guidance favors XML tags around each kind of content, a reason given for every rule, and long material placed above the question.
- Wrap each kind of content (context, instructions, examples, pasted material) in its own XML tag with a plain, consistent name.
- Put long documents and data near the top, and the question or task at the end.
- State the task explicitly, with the output format and constraints. If extra depth or polish is wanted, ask for it outright.
- Give the reason behind an instruction or constraint, such as what the output will be used for, instead of a bare command.
- Describe the format to produce, such as flowing prose paragraphs, instead of listing formats to avoid.
- When examples are used, give three to five varied ones, each in
<example>tags inside one<examples>block. - Use a numbered list for steps when their order or completeness matters.
- Write in calm, plain language. Leave out capitalized emphasis and be-thorough nudges, which current models over-apply, and do not ask the model to print its reasoning.
- A one-sentence role is enough when a particular expertise or voice is wanted.
Sources: Prompting best practices, Prompting Claude Opus 5.5. Checked October 10, 2026.
GPT
OpenAI’s guidance favors Markdown-headed sections, one outcome with its success criteria, and no instruction said twice.
- Divide a long prompt into sections with Markdown headings, and wrap pasted documents and examples in XML tags.
- Order the sections: role, goal, success criteria, constraints, output, stop rules. Put request-specific documents and data near the end.
- State the outcome and what success looks like. Describe the destination instead of prescribing every step.
- Say what to do when information is missing: name the missing fact, use the smallest useful fallback, and ask only for the one thing needed.
- State each instruction once and remove anything that contradicts another instruction.
- Keep absolute words (always, never, must) for true invariants. Write judgment calls as decision rules.
- For a short answer, name what it must contain and what to trim first, instead of a blanket request for brevity.
- State the response shape explicitly: paragraphs or lists, and when each is appropriate.
- Replace broad tone labels with the concrete writing choices that produce that tone.
- Keep an example only if it changes the result.
Sources: Prompt engineering, Using GPT-6. Checked October 10, 2026.
- 1RoleWho the model is writing as.
- 2GoalThe outcome you want.
- 3Success criteriaWhat a good answer must do.
- 4ConstraintsWhat it must not do.
- 5OutputThe response shape: paragraphs or lists.
- 6Stop rulesWhen to stop, such as on an empty input.
- 7Documents and dataRequest-specific material near the end, in XML tags.
Source: OpenAI prompt engineering guide, checked October 10, 2026.
Gemini
Google’s guidance favors short, direct prompts, one delimiter style used throughout, and the question placed after the material.
- Put long documents, code or data first and the specific question at the very end.
- After a long block of material, open the question with a short phrase that points back to it.
- Mark out role, constraints, context and task with XML-style tags or with Markdown headings. Pick one style and keep to it.
- State the goal plainly. Remove persuasion, flattery and pressure.
- Keep the prompt short and direct. Strip scaffolding written for older models, which Gemini 3 may over-analyze.
- Gemini 3 answers tersely by default, so ask explicitly when a detailed or conversational answer is wanted.
- Replace vague or subjective words with measurable definitions.
- Give few-shot examples identical structure and formatting, and pair them with written instructions.
- Do not ask the model to write out its plan or reasoning steps; it reasons internally.
- When the answer must come only from supplied material, say so, and say what to do if the answer is not there.
Source: Prompt design strategies. Checked October 10, 2026.
Where they differ
Set side by side, the differences are mostly about separators, order and defaults.
| Topic | Claude | GPT | Gemini |
|---|---|---|---|
| Separating parts | An XML tag for each kind of content, with plain, consistent names. | Markdown headings for sections; XML tags around pasted documents and examples. | XML-style tags or Markdown headings. Pick one style and keep to it. |
| Where material goes | Long documents and data near the top; the question or task at the end. | Instructions first (role, goal, success criteria, constraints, output, stop rules); request-specific documents and data near the end. | Long material first; the question at the very end, opened with a phrase that points back to the material. |
| Instructions | Give the reason behind each instruction or constraint. | State each instruction once. Absolute words only for true invariants; judgment calls as decision rules. | Short and direct. Replace vague words with measurable definitions. |
| Answer length | If extra depth or polish is wanted, ask for it outright. | For a short answer, name what it must contain and what to trim first. | Terse by default; ask explicitly for a detailed or conversational answer. |
| Examples | Three to five varied examples inside one examples block. | Keep an example only if it changes the result. | Identical structure and formatting, paired with written instructions. |
| Reasoning | Do not ask the model to print its reasoning. | Not addressed in the rules summarized here. | Do not ask for the plan or reasoning steps; it reasons internally. |
| Missing information | Not addressed in the rules summarized here. | Name the missing fact, use the smallest useful fallback, ask only for the one thing needed. | If the answer must come from supplied material, say what to do when it is not there. |
“Not addressed” means only that the point is not among the rules summarized here; follow the source links for each vendor’s full text. Whatever the model, saying what to do when information is missing is still worth doing. It is the ninth of the ten checks.
- Claude: Material later in the prompt 1/10, More markup between parts 9/10
- Gemini: Material later in the prompt 2/10, More markup between parts 6/10
- GPT: Material later in the prompt 9/10, More markup between parts 6/10
- Any chat model: Material later in the prompt 2/10, More markup between parts 2/10
Illustrative: positions are a reading of each vendor’s published guidance, not a measurement. GPT is the one that puts request-specific material last.
One prompt, three layouts
Here is the same request laid out three ways: summarize a meeting transcript into decisions and action items for teammates who missed it. The content is the same in all three. Only the separators and the order change.
You write meeting summaries for a product team.
<transcript>
{{transcript}}
</transcript>
<context>
The summary goes to teammates who missed the meeting. They will read it on their phones to learn what was decided and what they owe.
</context>
<instructions>
Summarize the meeting in the transcript above.
1. List each decision in one sentence.
2. List each action item with its owner and due date.
3. If the transcript gives no owner or no date, write "not stated", because the team will follow up on those, and a guess would send them to the wrong person.
Use two short headings, "Decisions" and "Action items", each followed by short plain sentences.
</instructions>
# Role
You write meeting summaries for a product team.
# Goal
Tell teammates who missed the meeting what was decided and what they owe.
# Success criteria
- Every decision in the transcript appears once.
- Every action item has an owner and a due date, or says "not stated".
# Constraints
- Use only what the transcript says.
# Output
Two bulleted sections, "Decisions" and "Action items". One line per item.
# Stop rules
If the transcript is empty or is not a meeting, say so in one sentence and stop.
# Transcript
<transcript>
{{transcript}}
</transcript>
<role>
You write meeting summaries for a product team.
</role>
<constraints>
Use only the transcript. If it gives no owner or no due date for an action item, write "not stated".
</constraints>
<format>
Two bulleted lists headed "Decisions" and "Action items". At most 20 words per item.
</format>
<transcript>
{{transcript}}
</transcript>
<task>
Based on the transcript above, list the decisions made and the action items, with owner and due date, for teammates who missed the meeting.
</task>
What to notice:
- Claude puts the long transcript near the top, gives a reason for the “not stated” rule, and describes the format it wants rather than formats to avoid.
- GPT follows the recommended section order (role, goal, success criteria, constraints, output, stop rules) and puts the request-specific transcript at the end, wrapped in a tag.
- Gemini uses one tag style throughout, stays short, turns “short” into a measurable limit, and ends with the question, opened by “Based on the transcript above”.
Will the layout change your results? Sometimes a little, sometimes not at all. The honest way to find out is to test it on your own inputs.
Coding agents
Coding agents such as Claude Code and Codex work inside a repository, so the brief is less about tags and more about pointers and proof. Anthropic and OpenAI ask for the same brief: the outcome, where to look, what must not change, and a check the agent can run.
- Lay the brief out as plain labeled parts, such as Goal, Context, Constraints and Done when. No tags or headings are needed.
- Describe the outcome, not the keystrokes. For a bug, give the symptom, the likely location and what fixed looks like.
- Name the files and interfaces involved, and paste the exact error instead of describing it.
- Point to an existing file or pattern in the codebase to follow, and state what must not change.
- Name a check the agent can run, such as tests, a build or a linter, and tell it to run the check and iterate until it passes. Ask for the command it ran and its output as evidence.
- For a change that spans several files or is uncertain, ask for a plan before any edits.
Goal: The CSV export on the Reports page drops any row whose customer name contains a comma. Fix it so every row is exported. Context: The export is built in src/reports/export.ts. A customer named "Smith, Jones & Co" is missing from the file; no error is logged. Follow: the quoting approach already used in src/invoices/csv.ts. Constraints: Do not change the column order or the file name. Do not touch the PDF export. Done when: a test exports the three rows in test/fixtures/commas.json and all three appear, quoted correctly. Run npm test and iterate until it passes, then show the command you ran and its output.
Sources: Claude Code best practices, Codex prompting. Checked October 10, 2026.
Image and video models
Image and video models read a description, not a request, and each tool has its own habits. In brief:
- Midjourney wants the picture described, not requested: remove words such as make, draw and please. Put exclusions in a trailing
--nolist and all parameters last, such as--arin whole numbers. Sources: Prompt Basics, Parameter List. - Plain-language image models such as Google’s Nano Banana and OpenAI’s GPT Image want the scene described concretely. Google’s models want full sentences rather than keyword lists, and the wanted state (an empty street) rather than “no cars”; for GPT Image, end with a line listing what to leave out. Put any text to be rendered in double quotation marks. Sources: Gemini image generation, OpenAI image prompting.
- Video models such as Veo and Runway want one shot described in film terms (dolly shot, eye-level, close-up), with sound written in sentences of its own after the visuals. Exclusions depend on the tool: Veo takes a plain list in its negative-prompt field, while Runway wants the positive version, such as sharp focus instead of not blurry. Sources: Veo in the Gemini API, Google’s video prompt guide, Runway: introduction to prompting.
The Grader has a Written for setting for each of these: Coding agent, Midjourney, “Image model, plain language” and Video model. The Fit test and the rewrite follow the rules for the one you pick.
Keeping up
Vendor guidance changes when models change. The rules in this guide were checked against each vendor’s documents on October 10, 2026, and the date at the top of this page changes when they are checked again. Three habits keep you current without reading every changelog:
- Follow the source links above when a new model ships, and look for what changed in the layout advice.
- Keep the reasons in your prompts. A rule with a reason survives a model change better than a bare command.
- Re-run your test suite on the new model before you switch. Guidance tells you where to start; your own cases tell you whether it worked.
Key takeaways
- Content matters more than layout, and the content rules are shared: a plain task, explicit format, calm wording.
- Claude: XML tags per kind of content, material on top, a reason for each rule.
- GPT: Markdown sections in a set order, documents near the end, each instruction once.
- Gemini: short and direct, one delimiter style, material first and the question last.
- For an unknown model, use plain labels, material before the question, and a stated length and format.
- Coding agents need pointers, limits and a check to run; image and video models need a description, not a request.
- Guidance is a snapshot. Re-check at each model release and test on your own inputs.