Most people rewrite a prompt from scratch each time they need something similar. Separating the stable parts from the variable ones turns a lucky result into a repeatable one.
What belongs in the fixed part
The fixed portion carries everything that is true of every request of this type: the role, the output format, the constraints, the terminology and the things to avoid.
It should be written once, carefully, and then left alone, because its stability is what makes results comparable across uses.
Anything that changes per request does not belong here, however tempting it is to hard-code a good example. A value fixed into this section will eventually be applied to a request it does not suit, silently.
Why slots beat rewriting
Variable content goes into clearly marked positions: the subject, the audience, the source material, the length.
Filling slots takes seconds and produces output whose quality is predictable, since only the intended variable changed.
Marking the slots distinctly also makes it obvious when one has been left empty, which is a frequent cause of confusing output. An unfilled slot produces text about the wrong subject rather than an error, so the failure is easy to miss.
How examples get versioned
Templates that include sample outputs work well and go stale, because the samples encode preferences that change.
Keeping the examples in a separate block, dated, makes it possible to swap them without touching the instructions.
When output quality drifts, the examples are usually the cause and the first thing to check. Samples chosen for one audience quietly steer every later request towards that audience.
Why a template needs failing cases
Every template should carry three or four requests that previously produced bad output, kept as a test set.
Running them after any edit reveals whether a change intended to fix one behaviour has broken another, which happens often and silently. Four cases take a minute to run and catch most regressions.
Without this, templates accumulate edits and slowly regress, and nobody can identify which change caused it.
Where templates stop paying
Templates suit repeated tasks with stable requirements and are overhead for one-off requests.
They also fail when the underlying task is genuinely varied, since a template that must accommodate every case becomes a long conditional document that follows none of its own rules well.
The useful test is whether the same request shape recurs weekly; below that frequency, maintaining the template costs more than writing the prompt each time.