The $variable pattern: writing prompts your whole team can reuse

Here's a prompt someone on your team probably wrote this week:

Write a follow-up email to Acme Corp about the Q3 renewal. They went quiet after our last call on pricing. Keep it warm but direct, two short paragraphs, and mention that the enterprise tier now includes SSO.

It's a good prompt. It also dies the moment it's used. Tomorrow, when the same person needs a follow-up to a different account about a different deal, they'll rewrite the whole thing from scratch — or worse, copy the old one and hand-edit "Acme" out of four places, missing one.

Multiply that by a team of twelve people, each rewriting the same five prompts every week, and you've got a quiet, invisible tax on everyone's time. Nobody notices it because each individual rewrite only takes a minute.

The fix is a habit, not a tool. It's the difference between writing a prompt and writing a template. And the whole habit comes down to one question you ask about every specific detail in your prompt:

"Will this be different next time?"

If yes, it's a variable. Pull it out.

What a variable actually is

A variable is a named slot for something that changes between runs. Instead of baking Acme Corp into the text, you write a placeholder — we'll use the $ convention, so $company — and fill it in at the moment you run the prompt.

Here's the same prompt, rewritten as a template:

Write a follow-up email to $company about the $deal. They went quiet after our last call on $sticking_point. Keep it warm but direct, two short paragraphs, and mention that $new_feature.

Now it's reusable. To run it, you fill four slots:

• $company → Acme Corp
• $deal → Q3 renewal
• $sticking_point → pricing
• $new_feature → the enterprise tier now includes SSO

Same output as before. But this version works for every follow-up email, not just the Acme one. You wrote it once; your whole team can run it forever.

That's the entire pattern. The rest of this post is about doing it well — because the difference between a template people reach for and a template people ignore is all in the details.

Spotting what should be a variable

The instinct most people get wrong is to variable-ize too little or too much. Here's the line.

Make it a variable when it's the subject of the task. The company, the deal, the customer's objection, the target audience, the topic, the deadline — these are the things that change every single time you run the prompt. They're what the prompt is about.

Keep it hardcoded when it's the instruction. "Keep it warm but direct," "two short paragraphs," "return the answer as a bulleted list" — this is the shape of the output, and it's the reason the template is worth saving. It's your accumulated taste, baked in. Don't parameterize it, or you've just recreated a blank prompt.

A quick test: read the detail out loud and ask "is this what makes this task this task?"

• "Acme Corp" — yes, that's the subject. → Variable.
• "two short paragraphs" — no, that's how I always want follow-ups. → Hardcode it.

A well-built template is a stable skeleton (your instructions) with a few clearly-marked slots (the specifics). If you find yourself variable-izing the tone or the format, stop — you're dissolving the very thing that made the template worth keeping.

Naming variables so a teammate can use them

The moment a template leaves your head and lands in a teammate's, the variable names become the entire user interface. If your colleague can't tell what goes in a slot without asking you, the template has failed.

Three rules earn their keep:

1. Name the role, not the example. Write $company, not $acme. The name should describe what kind of thing fills the slot, so it reads correctly no matter what you put in it. $acme filled with "Globex" is confusing; $company filled with "Globex" is obvious.

2. Be specific enough to be unambiguous. $name is a trap — name of what? The customer? The rep? The product? Prefer $customer_name, $rep_name, $product_name. A slightly longer variable name is a tiny cost; a teammate filling in the wrong value is a real one.

3. Stay consistent across your whole library. If one template uses $company and another uses $account and a third uses $client — all for the same concept — you've made your team memorize three words for one thing. Pick one and use it everywhere. Consistency is what lets someone move between templates without re-learning the vocabulary each time.

The underrated payoff of good names: a well-named template is often self-documenting. $company, $deal, $sticking_point, $new_feature — you can hand that to a new hire and they know exactly what to do, with zero explanation.

Why $company beats "the company"

This is the subtle one, and it's worth slowing down for.

You could write your template with prose placeholders — "write a follow-up to the company about the deal" — and just mentally substitute as you read. Plenty of people do. But a marked, named token like $company buys you three things that prose placeholders can't:

It's machine-findable. A distinct token like $company can be reliably located and swapped — by a find-and-replace, by a fill-in form, by a tool. "The company" appears in ordinary sentences and can't be safely auto-detected or substituted; you'll clobber the wrong words.

It's unambiguous at fill time. When you run the template, $company and $deal are two obviously-distinct slots to fill. "The company... the deal..." blurs into the prose, and it's easy to fill one and forget the other.

It survives reuse. Prose placeholders get accidentally "finished" — someone reads "the company," pictures Acme, and writes "Acme" into the saved template. Now it's broken for the next person. A $company token is visibly a slot; nobody mistakes it for a filled-in value.

That last point is why marked tokens matter most for shared templates specifically. A prose placeholder is a note-to-self that quietly rots. A named token is a contract: this is a slot, it stays a slot, fill it at run time.

A worked example

Let's take something messier than an email. Say your team writes release notes, and everyone does it a little differently. Here's a raw prompt one person uses:

Summarize these git commits into release notes for the March update of Dashboard. Group them under Features, Fixes, and Improvements. Write for non-technical users — no jargon. Skip anything internal-only like CI changes.

Now let's find the slots. Read each detail and ask "different next time?":

• "these git commits" → different every release. → $commits
• "March update" → different every release. → $release_name
• "Dashboard" → different if we ship notes for multiple products. → $product
• "Features, Fixes, Improvements" → same every time; this is our house style. → hardcode.
• "non-technical users, no jargon" → same every time; this is our voice. → hardcode.
• "skip internal-only like CI changes" → same every time; this is our rule. → hardcode.

The template:

Summarize $commits into release notes for the $release_name update of $product. Group them under Features, Fixes, and Improvements. Write for non-technical users — no jargon. Skip anything internal-only like CI changes.

Three slots, all clearly the subject of the task. Everything that encodes the team's taste — the grouping, the voice, the exclusion rule — is locked in. Anyone can now produce on-brand release notes for any product by filling three fields. The team's standard travels with the template instead of living in one person's head.

Where templates want to live

Once you've got a handful of these, the last question is where they go — because a great template saved in one person's notes app helps exactly one person.

The scrappy version: a shared doc. It works, barely. The problems show up fast — no one knows which version is current, the variables drift out of the naming convention you agreed on, and there's no clean way to "run" a template except copy-paste-and-hand-edit, which reintroduces exactly the error you were trying to design out.

The proper version is a shared library where templates are first-class objects: named, versioned, and runnable — you pick a template, a form asks you for $company and $deal, and it hands you the finished text with every slot filled correctly. This is the model we built Korvai around: your team's prompts and skills live in one place, variables use the $name convention throughout, and running a template means filling a form, not find-and-replacing by hand. You can even browse and grab a shared template — fill its variables live — without an account, to feel the difference between a prompt and a template.

But the tool is the easy part. The habit is what matters, and you can start it today, in whatever you already use:

1. Next time you write a prompt you'll use again, stop before you save it.
2. Read every specific detail and ask "different next time?"
3. Turn each "yes" into a named $variable — role, not example.
4. Leave your instructions hardcoded. That's the part worth keeping.

Do that five times and you'll have a small library of templates that your whole team can run — and you'll stop paying the tax of rewriting the same prompt every Monday morning.