A saved prompt that worked last month quietly stops working. Not because the model changed — usually it has not — but because the prompt was never a template. It was a sentence that happened to produce a good result once, and the conditions that made it work are no longer present.
The difference between a prompt that keeps working and one that decays is the same difference as between a recipe and a lucky meal. One states what is fixed and what varies. The other is a memory of something that turned out well.
Here is how to write the first kind, in a form a colleague can use without understanding why it works.
Why saved prompts decay
Ask someone to hand over their best prompt and you usually get a paragraph with everything mixed together: the persona, the task, the style, the constraints, and a specific example, all in one flowing block.
That block works while the task is identical to the original. Change the topic and the example no longer fits, so it either gets removed — taking the style instructions with it, because they were embedded in the example — or it stays and contaminates the output with details from a different subject.
The decay is invisible because it is gradual. Output quality drops a little, the user adds a sentence to compensate, the sentence stays, and after a few months the prompt is a sediment layer of fixes for problems that no longer exist.
The anatomy of a usable template
A template has four parts, and they should be visually separable. Anyone editing the prompt later should be able to tell which part they are changing.
- Role and objective. What the output is and who it is for. One or two sentences.
- Inputs. The slots. These are the only things that change between uses.
- Rules. Constraints that apply to every output, expressed as checkable conditions.
- Output shape. The structure of the response — headings, length, format.
Keeping rules separate from inputs is the whole trick. Rules are permanent; inputs are filled per use. When the two are interleaved, every new task forces a decision about which parts to keep, and people under time pressure keep the wrong ones.
Fixed rules versus fillable slots
Write slots in a form that cannot be mistaken for content. Bracketed names work well because they are visually obvious in a wall of text: [AUDIENCE], [PRIMARY_CLAIM], [EVIDENCE], [CONSTRAINT].
Then decide, for each slot, whether it is required or optional. A required slot with no value should stop the process rather than produce a guess — that is the point of having it. An optional slot should have a stated default, so that leaving it empty is a decision rather than an omission.
The temptation is to add slots until the template covers every case. Each slot is a question the user has to answer before they get output, and a template with twelve slots will be filled in badly or abandoned. Four to six is usually the working range; anything more belongs in a second, more specialised template.
Writing rules you can check
A rule that cannot be verified against the output is not a rule. "Write in an engaging style" cannot be checked, so it cannot be enforced, so it does nothing except take up space.
Compare it with rules that can be verified mechanically:
- Maximum twenty words per sentence.
- No sentence may open with a definition of a common term.
- Every claim of improvement must be accompanied by a specific before-and-after.
- Do not state a statistic. If a number is needed, use one supplied in
[EVIDENCE]. - No more than two adjectives applied to the same noun.
These feel restrictive, and that is the function. Each one removes a specific failure that someone on the team kept fixing by hand. A rule list is not a description of good writing in general; it is a record of the mistakes this particular process makes.
Start with an empty rule list and add one rule each time you correct the same mistake twice. Templates built this way stay short and every line in them earns its place.
Naming and versioning
Name templates by the job, not by the output. product-description-v2 is a name. final-prompt-good-one is a name that guarantees nobody will know which to use in a month.
Version in the open. Changing a rule changes outputs for everyone using the template, and people need to be able to tell which version produced a given result. A short changelog at the bottom of the file — date, what changed, why — costs almost nothing and prevents a genuinely painful debugging session where two people compare outputs produced by different rules.
Resist editing a template in place without a version bump. The one-line fix you make at the end of a busy day is exactly the change you will want to reverse next week, and without a version you cannot.
Testing before rollout
Before a template goes to the team, run it on three unrelated inputs. The goal is not to check quality on the intended case; it is to find the case where it breaks.
Specifically, look for three things. Does it hold its rules when the input is thin — when [EVIDENCE] has one item? Does it do something sensible when a slot is left empty? Does it produce the same shape of output across topics, or does the structure drift when the subject changes?
Thin input is the most important test. Templates usually fail there, because the model compensates for missing substance by generalising, and generalising is exactly what the rules were written to prevent.
When a template hurts
Templates are for repeatable work. Applied to exploratory work, they are actively harmful — they force the model toward an established shape at the exact moment you are trying to find a new one.
The distinction is whether you know what good output looks like before you ask. If you do, a template protects that standard. If you do not, you should be prompting conversationally, looking at several results, and only afterwards codifying whatever produced the best one.
A useful rule: write the template after the third time you do the same task, not before the first. By then you know which constraints matter and which were noise.
Handing it to someone else
The real test of a template is whether a colleague can use it without training. Ask them to produce one output from it and watch where they hesitate. Every hesitation is either a slot that needs a clearer name or a rule that needs an example.
Add one worked example to the template, and make it an unglamorous one. Examples built from boring inputs teach the format; examples built from impressive inputs teach people to imitate the example's subject matter instead of its structure.
The mark of a template that is finished is that it contains nothing personal. No reader should be able to tell who wrote it, and no result should depend on who ran it.