A portable prompt template needs six blocks in a fixed order: goal, inputs, constraints, output shape, refusal rules, and a length cap. Everything above those blocks is provider-specific, so the model agnostic part is not a shorter prompt. It is a structured one.
The model note is the other half. It is one or two lines appended per model that recover the behaviour you actually need, without forking your base prompt into three drifting copies. Below is the template, the notes, and a worked example of the same brief running across three products.
What makes a prompt portable
Portability fails for structural reasons, not length reasons. Four patterns break the moment you paste into a different product.
- Unfenced instructions buried in prose. If the model has to guess which sentence is the task, it will guess differently elsewhere. Number the blocks.
- Model-specific syntax. Vendor tags, tool-call formats, and chat-role conventions do not transfer.
- Implicit output expectations. "Make it a table" is a preference. "Return a table with these four columns and nothing outside it" is a contract.
- No refusal rules. Without them, every model fills gaps with plausible invention, and they fill them differently.
Everything you replace to adapt the prompt for a specific model belongs in the note, not the base.
The portable prompt template, one page
GOAL. [One sentence. The single job this prompt does.] INPUTS. Use only what I give you here: [paste or list inputs, in order]. If an input is missing, write [MISSING INPUT] for it and continue. CONTEXT. [Two to five short bullets. Audience, situation, constraints you actually know.] Do not assume anything not in these bullets. STEPS. [Numbered. What to do, in order.] OUTPUT SHAPE. [The exact format. Column names, field names, section order, or JSON keys.] Nothing outside this shape. LENGTH CAP. [Number] words. Cutting is allowed, padding is not. REFUSALS. Do not invent statistics, dates, prices, names, citations, or results. Do not use filler phrasing of the "in a fast-paced world" family. If a required fact is missing, write [CONFIRM: what you need] instead of guessing. If the inputs contradict each other, stop and name the contradiction.
Fill in these details
- Goal: One sentence, one verb. If you need "and" twice, split the prompt.
- Inputs: Ordered, and labelled. Ordering matters because context handling differs across products and the first and last items survive compression best.
- Context: Bullets, not a paragraph. Paraphrase waste survives in ways that break portability.
- Steps: Numbering is what lets you reference a step later, such as "apply step 3 to each row".
- Output shape: Field names are more portable than prose descriptions of format. State them literally.
- Length cap: A number in words, not "keep it concise". Concise is a preference, a number is a constraint.
The per-model note, in two lines
Append this after the base prompt. Change only what you are actually correcting.
MODEL NOTE. [One or two lines. For example: list your top three assumptions before the answer, then give the answer. Or: return the output shape as a fenced code block with no commentary outside it.]
What belongs in a note, drawn from what practitioners usually have to fix:
- ChatGPT: a request to return the shape inside a fenced code block, or to add a short assumptions list before the answer, when it otherwise front-loads commentary.
- Claude: a request to state the goal back in one sentence before answering, or an explicit instruction to show reasoning as a short numbered plan before the deliverable.
- Gemini: an instruction to attach sources or state plainly that no source was available, when the task depends on external facts.
- Any model, streaming products: an instruction to write the whole answer before showing anything, or to avoid partial preambles.
These are habits worth testing, not documented rules. Providers change defaults between releases, so re-check your notes whenever a product updates.
Worked example: one brief, three models, one base prompt
A freelancer needs a project kickoff email to a client who has already approved a scope verbally but has not signed.
Base prompt, goal block:
GOAL. Write a project kickoff email that confirms scope in writing and asks for signature, without sounding like a chase.
Base prompt, output shape block:
OUTPUT SHAPE. Return a table with columns: section, draft line, why this line exists. Then return the full email as one block with no headings.
Refusal block does the real work here:
REFUSALS. Do not invent dates, prices, deliverables, or contract terms. Do not imply a deadline I did not give. If a date or term is needed, write [CONFIRM: date or term] at the end of the relevant line.
ChatGPT note: "Return the email inside a fenced block, no preamble." Claude note: "Restate the goal in one sentence, then give the table, then the email." Gemini note: "After the email, list anything you would need to verify externally."
The base prompt is byte-identical across all three. Only the note moves. That is the entire maintenance cost of one prompt all ai models.
How to check a prompt is genuinely model agnostic
1. Paste it cold into two products you did not write it for
If it works when you have no prior knowledge of the prompt, it is portable. If it only works after a conversation, it is not.
2. Change the input order and re-run
If moving a bullet from top to bottom changes the answer materially, the prompt was leaning on position rather than structure. Number the blocks.
3. Give it deliberately incomplete inputs
A portable prompt should surface gaps as [CONFIRM] markers rather than filling them. If a model invents instead, its refusal block is too weak.
Common portable prompt mistakes
- Adding vendor syntax to the base. Tool tags and role conventions belong in the note or nowhere.
- Letting the note grow into a second prompt. If your note exceeds three lines, the base is missing a block.
- Copying the base per model. Copies drift. Keep one base and a note.
- Testing portability on a trivial task. Try a real task with messy inputs, since short tasks hide structural gaps.
- Trusting a note you wrote six months ago. Defaults change. Re-run and update.
Frequently asked questions
What makes a prompt model agnostic?
Structure, not brevity. A model agnostic prompt states its goal, inputs, constraints, steps, output shape, length cap, and refusals as separate numbered blocks, and depends on no vendor-specific syntax.
Should the length cap be the same for every model?
Usually yes, since it reflects your real constraint rather than the model's verbosity. If one product routinely returns double, tighten that note rather than relaxing your actual limit.
Is one base prompt worse than three tailored prompts?
For anything you run repeatedly, one base plus notes is better, because you maintain one source of truth. For a one-off high-stakes deliverable, tailoring the whole prompt is worth the effort.
Save the base, tune the note
Write the base prompt once, paste it into each product unchanged, and keep a single note line per model that you revise after each test. In a month you will have a small, accurate map of how each model behaves on your work, which no comparison chart will give you. For the underlying mechanics, read the introduction to prompt engineering.