Prompt variables: turn one prompt into a thousand

You wrote a prompt for a 200-word LinkedIn post for HR managers about employee onboarding software. It works great. Tuesday you need a 200-word post for SaaS founders about pricing strategy. You copy the original prompt, edit "HR managers" to "SaaS founders," edit "employee onboarding software" to "pricing strategy."

Wednesday: same thing for fitness coaches. Thursday: another tweak. Friday: you have six similar prompts and you've forgotten which one had the best version of the statistic constraint.

That moment — copying-and-editing the same prompt with small tweaks — is the signal you should have used a variable. Variables turn one prompt into a hundred. They're the single highest-leverage move in prompt management. Done well, your library shrinks while your capability grows. Done badly, you end up with a 12-field form nobody wants to fill out.

The mental model: prompts as functions#

In code:

function summarize(text, max_words, tone) {
  // body
}

In prompts:

Summarize the text below in {{max_words}} words.
Tone: {{tone}}.

Text:
{{text}}

Same idea, different syntax. Variables wrap any name in double curly braces: {{audience}}. When you run the prompt, PromptShip asks you (or your teammate) to fill in each variable before it ever reaches the model. Same prompt body, different inputs, different outputs.

Syntax and naming conventions#

Two rules to lock in:

• Names should be short and explicit. {{topic}} beats {{x}} every time. The name shows up in the run-time form, so make it self-explanatory.
• Use snake_case or kebab-case consistently. Pick one and stick with it across your library. Mixed conventions look amateur fast and break library-wide search.

Bad prompt → good prompt: a real example#

Here is a perfectly mediocre, hardcoded prompt:

Write a 200-word LinkedIn post for HR managers about
employee onboarding software. Tone should be professional
but not boring. Include one statistic.

Every time the audience or topic changes, you edit the prompt by hand and risk forgetting a phrase. Now the same prompt as a template:

Write a {{word_count}}-word LinkedIn post for {{audience}}
about {{topic}}.

Tone: {{tone}}.
Constraints:
- Lead with a hook (no "I'm excited to announce")
- Include exactly one statistic, with a credible source
- End with a single open-ended question

Same prompt body. But now it produces a post for HR managers, then 30 minutes later a post for SaaS founders, then a post for fitness coaches — without you re-writing anything except the variable values. The structural quality stays consistent because the template stayed the same.

When to extract a variable (and when not to)#

Not everything should be a variable. Over-templating creates a form with 14 fields no one wants to fill out. The rule of thumb:

Three template patterns that earn their keep#

Pattern 1: Audience + content#

The same content explained for different audiences. The classic use case: turning one technical write-up into a marketing post, an exec summary, and a customer email.

Rewrite the content below for a {{audience}} audience.

Reading level: {{reading_level}}.
Length: {{word_count}} words.
Format: {{format}} (e.g., bullet points, paragraphs, tweet thread).

Preserve every factual claim. If you remove technical detail,
do not invent new claims to fill the space.

Content:
"""
{{source_content}}
"""

Pattern 2: Data + action#

Feed the model some structured input plus a verb. Used for summarization, extraction, transformation. The shape almost never changes — only the data and the action.

{{action}} the following {{data_type}}.

Output format: {{output_format}}.
Constraints: {{constraints}}.

If a field is missing, write "n/a" — do not guess.

Input:
"""
{{input_data}}
"""

Pattern 3: Role + task + context#

The most common production prompt shape. A persistent role, a concrete task, and the per-run context. This is the structure behind almost every customer-facing AI feature.

You are {{role}} at {{company}}.

Your task is to {{task}}.

Use these constraints — do not deviate:
{{constraints}}

Context for this specific request:
"""
{{context}}
"""

Give every variable a smart default#

The fastest run-time experience is one where most fields are already filled in correctly. Save default values for variables that are usually the same — your team can override only the few that change.

Example: a {{tone}} variable defaults to "warm and direct". Most days, you accept the default. Once a quarter, you override it to "executive and terse" for a board update. Defaults turn a 6-field form into a 1-field interaction most of the time.

Going further: production variable patterns#

Typed variables and validation#

For variables with restricted values (categories, languages, severity levels), use enum constraints — {{tone}} with allowed values warm | executive | technical. The form becomes a dropdown instead of a free-text field, eliminating typos that would silently change model behavior.

Per-context defaults#

Different contexts call for different defaults. The same template might want {{tone}}=warm on the customer-support team and {{tone}}=technical on the engineering team. Use workspace-level or project-level defaults so each team gets the right starting values.

Derived variables#

Some variables can be computed from others. If you have {{customer_name}} and {{customer_id}}, you might derive {{customer_url}} automatically rather than asking the run-time author for it. Reduces form burden without losing precision.

Versioning templates as a unit#

Adding or removing a variable is a breaking change — every workflow that calls the template might break. Treat it like an API schema change: bump the version, document what changed, communicate to teammates. See version control for prompts.

Common mistakes#

• Variable names that aren't self-explanatory. {{a}}, {{x}}, and {{thing}} are crimes. Future-you reading the run-time form has no idea what to type. Spend the extra two seconds.
• Inconsistent naming across the library. Picking {{customer_name}} in one prompt and {{customerName}} in another. Pick one convention. Document it. Stick to it.
• Variabilizing the entire prompt. If your prompt is just {{instructions}} followed by {{input}}, you have not made a template. You have made a chat box with extra steps.
• Forgetting that variables travel with the prompt. When you share a prompt with your team via the team library, the variable spec goes with it. Bad variable names hurt every teammate who runs the prompt.
• Skipping defaults. Every field without a default forces a decision at run time. Most fields have obvious defaults — populate them.

Quick reference#

Next: keep history when you change a template#

Once you start tweaking templates — and you will — you need a way to track changes and roll back regressions. That is the next guide: Version control for prompts.

Prefer to learn by example? Browse the public prompt library — almost every featured prompt uses variables, and you can clone any of them into your own workspace with one click.