Template It or Write It Fresh? (A Decision Rule)

TL;DR: Before you write a prompt, decide whether it's worth turning into a reusable template or just writing fresh: use the three-times rule. If you can already picture doing something recognizably similar three or more times, spend the extra few minutes templating it now. If you genuinely can't picture a second time, write it fresh and don't look back.

What's the Actual Decision You're Making Here?

Not whether templates are good. They are, and if you've read anything about prompt libraries you already know that. The decision that actually trips people up is smaller and more immediate: right now, staring at a task, do you spend the extra five or ten minutes turning this into a parameterized template, or do you just write the thing and get on with your day?

Get this wrong in one direction and you burn time templating a genuine one-off you'll never touch again. Get it wrong in the other direction and you're rewriting a near-identical prompt from partial memory every single week, slightly worse each time because you're reconstructing it instead of reusing it. Both failure modes are common, and neither is really about prompt-writing skill. They're about not having a rule for the moment the decision actually gets made, which is before you've typed anything.

What Is the Three-Times Rule?

If you can already picture doing a recognizably similar task three or more times, invest the extra effort to templateize it now, before you even finish this instance of the task. If you genuinely can't picture a second occasion, or you're only guessing there might be one, write it fresh and move on without a second thought.

That's the whole rule, and it's meant to be quotable precisely because the actual decision has to happen fast, mid-task, not as a separate planning exercise. You don't have time, in the moment, to run a multi-factor analysis of a prompt's long-term reuse potential. You have time to ask yourself one question: have I done something like this before, and will I again, at least twice more?

Why Three, and Not One or Five?

Once could be a coincidence. A task that's come up exactly one time before doesn't tell you much about whether it'll come up a third time, and templating on a sample size of one is usually a bet you'll lose more often than win. Five is defensible but overcautious: waiting for five occurrences before you template means you've already paid the "write it from scratch" cost four separate times, which is most of the total cost you were trying to avoid.

Three is the point where a task stops looking like a coincidence and starts looking like a pattern. It's not a law of prompting, it's a heuristic, and heuristics exist precisely because you don't have the information to calculate the exact answer in the moment. The number that matters less than getting a number at all: pick a threshold, apply it consistently, and stop relitigating the decision every single time a similar task shows up.

The math backs the intuition up. A template costs roughly five to ten extra minutes over writing the prompt once, for stripping out the specifics and adding placeholders. Writing the same shape of prompt fresh costs two to five minutes each time, plus a quieter cost: a rewritten-from-memory prompt is usually a slightly worse version of the one you refined last time, because you're reconstructing intent instead of reusing a tested instruction.

That breakeven point is doing the real work in the three-times rule. By the third occurrence you've usually already crossed it, which is exactly why three, not one, is the trigger.

What Makes a Task "Template-Shaped" in the First Place?

Recurrence alone isn't enough. A task also has to have a stable shape underneath its variation: the same structure, the same sequence of instructions, with only a handful of specifics changing between instances. If you can already name what those specifics are, the audience, the client, a tone, a word count, before you've even built the template, that's the signal the task is template-shaped.

The test in practice: picture the next occasion this task comes up. Can you point at exactly what would be different, a name here, a number there, while the rest of the instructions stay word-for-word identical? If yes, you're looking at a template with some blanks in it. If every occurrence would need a genuinely different structure, not just different values in the same slots, you don't have a template candidate. You have a family of unrelated one-offs that happen to share a topic, which is a much weaker basis for templating than sharing a shape.

When Should You Not Template It, Even If It Recurs?

When the value of the task is in discovering the structure fresh each time, not in reusing one you've already found. Creative or exploratory work, brainstorming a new angle, drafting an experimental piece, working through a problem you don't yet understand, often recurs constantly and should still be written fresh almost every time.

The reason is subtle but important: a template locks in last time's answer to "what structure works here," and exploratory work is precisely the kind of task where you want the structure to be part of what you're discovering, not a constraint you inherited from a previous attempt. Force a fixed brainstorming template onto every session and you cap the ceiling at whatever worked before, which is the opposite of what exploration is for. Recurrence tells you a task is common. It doesn't automatically tell you the task benefits from being fixed in place.

What Does the Rule Look Like Applied to Three Real Tasks?

A code review pass on incoming pull requests. You've done this three times this week alone, on different diffs, with the same severity rubric each time. Obvious template: the structure never changes, only the diff does. Build it now, before the fourth review, not after.

An apology email about one specific missed deadline. Every detail, the client, the date, the reason, is unique to this exact situation, and there's no reasonable version of "this happens again" beyond the generic fact that deadlines sometimes slip. Write it fresh. Templating it buys you nothing, because the next missed deadline will need entirely different specifics wrapped around a structure you'd have to rebuild anyway.

An investor update you've sent twice and might send again. This is the genuinely ambiguous case, and it's worth naming rather than pretending the rule always resolves cleanly. Two occurrences, a plausible third. The honest move: apply the rule as written, which says wait for three, but keep a rough copy of what you wrote either way. If a third update happens, you've lost nothing by waiting; if it doesn't, you never paid the templating cost on something that turned out to be closer to a two-time task.

That third case is the point worth remembering: the rule is meant to resolve the easy, obvious majority of decisions instantly, so you can spend actual thought on the small share that are genuinely ambiguous, not to pretend every case resolves as cleanly as the first two.

Notice what the three examples have in common beyond their verdicts: in every case, the decision was available before the task was finished, not after. You didn't need to complete three code reviews to know the fourth was coming; the pattern was visible by the second. That's the whole point of treating this as a prospective rule rather than a retrospective one, catching the decision while it's still cheap to act on, instead of noticing in hindsight that you've quietly rewritten the same prompt five times.

How Does This Decision Fit Alongside Other Prompting Choices?

It sits in the same family as a handful of other "which approach, when" calls that prompting keeps forcing on you, and it's worth treating it the same way you'd treat those: as a quick, repeatable rule rather than a fresh judgment call every time. Chain-of-thought prompting covers when explicit step-by-step reasoning earns its keep versus when it just adds noise. Few-shot vs zero-shot covers when showing examples beats a plain instruction. RAG vs fine-tuning vs prompting covers a bigger, more expensive version of essentially the same tradeoff: build infrastructure once, or handle it inline every time. Template-or-fresh is the same shape of decision at the smallest, most personal scale: pay a little more once, or a little more every single time.

How Do You Actually Build the Template Once You've Decided?

Take the prompt you just wrote or are about to write, and replace whatever would change next time with a placeholder: a name, a number, an audience, a tone. Keep everything that would stay identical exactly as written, because that's the part of the prompt doing the actual work.

BEFORE — written for this one instance:
Write a short, direct email to Jordan explaining the invoice
discrepancy on #4821, and offer a $150 credit as a resolution.

AFTER — the same structure, generalized:
Write a short, direct email to {{client_name}} explaining the
billing discrepancy on invoice {{invoice_number}}, and offer
{{credit_or_adjustment}} as a resolution. State the discrepancy
plainly in the first sentence. One paragraph of explanation, no
more. End with a specific next step.

Once it's built, name it so it's actually findable later, not just saved. Naming prompts so you can find them later covers the naming side of this specifically: a template that's hard to name accurately is often a sign it wasn't quite as template-shaped as it seemed, which is worth noticing before you save it, not after.

What Happens to a Template a Few Months Later?

It either keeps earning its slot or it doesn't, and that's worth revisiting periodically rather than assuming a template decision made once stays correct forever. A task you expected to recur three times might have recurred once and then your role changed. Spring-cleaning your prompt library covers the periodic pass where you actually check that: which saved templates are still earning their keep, which should be merged with something near-identical, and which should be retired because the task they were built for stopped showing up. The template-or-fresh call gets you into the library correctly. The clean-out is what keeps the library honest about whether that call still holds.

On a capped plan, this decision has real weight behind it, not just tidiness. Prompt Architects' Pro plan holds up to 50 saved prompts before Advanced and Team remove the ceiling entirely, per the pricing page, which means every template you build on Pro is genuinely competing for a scarce slot against everything else you might save. Free-tier use skips this decision entirely, since there's no saved library to template into at all.