What prompt variables are (and what they're not)
A prompt variable is a placeholder inside a block of text that gets a new value each time you use it. In PAL you write it as {{client}} or {{tone}}, right inside the sentence where it belongs, and the rest of the text around it stays fixed. When you generate, which PAL calls Brew, a form asks for the current value, and the placeholder is replaced in the rendered output.
That's a narrower idea than it sounds. A variable is not a separate document, not a new prompt, and not a setting you configure somewhere else. It lives inside the block itself, in plain text, the same way you'd type any other word. PAL finds every {{token}} in a Blend automatically as you write it, so there's no separate list to maintain by hand and no step where you register a variable before you can use it.
It's also not the same thing as a custom instruction saved once per conversation. A custom instruction applies to everything in that chat. A variable applies to one specific spot in one specific block, and a single Blend can hold several different ones, each filled independently at generation time.
Why "one template, many clients" beats rewriting from scratch
Say you write content for three clients with roughly the same process: a tone rule, a formatting rule, a brief. If the only thing that differs between clients is a handful of details, typing three separate versions of the shared ninety percent isn't three different jobs. It's the same job typed three times, and it stays that way until something in the shared part needs to change, at which point it's three separate edits instead of one. Stop Rewriting the Same Prompts for Every Client goes deeper into why that habit forms in the first place.
A variable separates the part that's always true from the part that changes. Write the shared instructions once, with {{client}} marking the spot that isn't shared, and the same Blend serves every client. Only the value differs at generation time, so a later fix to the shared wording applies the moment you generate again, not the moment you remember to update three files.
This isn't limited to saved templates. Quick Brew runs the same fill-in-the-variables step without creating a Blend at all, for the cases where you need one output right now and don't want to build a reusable structure for a one-off request.
How to design variables that don't break: naming, scope, defaults
A few habits keep variables useful instead of confusing once a Blend has more than one or two.
Name them for what they hold, not for where they came from. {{client}} tells you what to type when the form appears. {{field_3}} doesn't. Since PAL discovers variables straight from your text, the name you choose in the block is the name you'll see on the fill-in form, so it's worth writing it the way you'd want to read it later.
Decide scope on purpose. A variable inside a global block gets filled every time that block is used, by whoever's generating, in whatever Project they're working in. If a value should really only ever change per client rather than per generation, that's often a sign the difference belongs in a project-scoped override block instead of a variable you retype every time.
Don't expect a variable to stay filled between generations. PAL substitutes the value only at the moment you generate; it isn't stored back into the block. If you want a value to persist as the default for a specific client going forward, write it directly into a project-scoped block instead of typing it into the variable form every single time.
A worked example: {{client}}, {{tone}}, {{deliverable}} in one template
Picture a single content-brief Blend built for reuse across clients, close in shape to the client brand-voice system in the gallery. The block reads something like: "Write a {{deliverable}} for {{client}} in a {{tone}} voice, following the brand rules below." Three variables, one shared paragraph, and a reference down to a global tone-of-voice block underneath it, the same block-referencing structure a reusable prompt system is built from.
At generation time, the form shows three fields. Fill in "blog post," "Acme Consulting," and "confident but plain," and the rendered prompt reads as a complete, specific brief with none of the placeholder syntax left in it. Switch clients and the same Blend produces a brief for a completely different account, changing only what actually needs to change.
Filling in the form takes a few seconds either way, whether the Blend has one variable or ten, and the fill-in step is the same one every time you generate, regardless of how the underlying Blend is composed. Once generated, the text is ready to copy. That's the actual handoff point: you take the rendered prompt and paste it into whichever model you're running that client's work through.
Variables vs. custom instructions in ChatGPT/Claude Projects
ChatGPT and Claude both let you save standing instructions for a project or a custom GPT. Those work well for something genuinely constant across every conversation in that space. Neither has a native way to mark one part of an instruction as fixed and one part as fill-in-per-use, so people commonly end up duplicating a custom instruction per client anyway, one saved project per account.
A variable-bearing Blend does something narrower and more specific: mark exactly the parts of a template that should change, keep everything else identical, and fill the changing parts explicitly at the moment you generate. It doesn't replace a model's own project settings. It's the layer that decides what actually goes into the prompt before it gets there, and that prompt still ends up copied into whichever model's project or chat you're using for the work.