Turn any prompt into a reusable fill-in template
Reusing a prompt usually means hunting through the text and hand-editing the
bits that change. This tool removes that friction: write your prompt once, mark
the parts that vary with {{double braces}}, and it builds a tidy form with one
field per variable. Fill the form and the finished prompt assembles live, ready
to copy — the same template works for every new run.
How it works
The tool scans your template for {{...}} tokens and collects the unique
variable names, preserving the order they first appear. It generates one input
per variable, so a placeholder used several times is filled just once and
updated everywhere. As you type, each occurrence is replaced with your value to
produce the final prompt. Anything you leave blank stays as {{name}} in the
output and is flagged as unfilled, so you never accidentally send a half-filled
template.
What makes a good template variable
Not every part of a prompt should become a variable. Over-templating makes the form tedious to fill in and the template fragile; under-templating means you still have to edit the raw prompt manually. The right parts to template are:
The subject or topic — the entity the prompt is about. “Write a product description for {{product_name}}” is the canonical example: the instruction structure is stable, only the subject changes.
The audience or persona — who the output is for. “Explain {{concept}} to {{audience}}” adapts a single explanation template to wildly different audiences without touching the instruction structure.
Constraints that vary by run — length, format, tone, language. “Summarise {{document}} in {{n}} bullet points using {{language}}” is one template covering dozens of use cases.
The input content itself — the document to summarise, the code to review, the email to reply to. A {{document}} variable lets you paste in the content at run time without touching the instructions.
What you should generally leave outside variables: the fixed instruction logic, the role definition, the output format requirements. These should be stable parts of the template that you deliberately design once and do not change per run.
Why the live preview matters
The immediate preview of the filled prompt serves a purpose beyond convenience — it lets you catch variable interactions before you send. When a template has multiple variables, filling them in can produce unexpected results: a long {{company_name}} may break a sentence’s grammar, a {{tone}} value of “formal” may clash with instructional language elsewhere in the template, or a number substituted into {{n}} might not make sense in the surrounding phrase.
Reading the filled preview takes five seconds and catches these issues before a wasted API call.
Building a family of related templates
One of the most powerful uses of this tool is building a small family of related templates for the same underlying task at different complexity levels. For example, a summarisation family might include:
- A short template:
Summarise {{document}} in one sentence. - A structured template:
Summarise {{document}} covering: main argument, key evidence, and conclusion. {{length}} sentences per section. - A domain-specific template:
You are a {{domain}} specialist. Summarise {{document}} for {{audience}}, focusing on {{focus_area}}.
Each template in the family shares the same core variable ({{document}}) but adds progressively more control. You pick the right template for the task’s complexity rather than editing one template for every use case.
Tips and notes
Use clear, descriptive variable names — {{target_audience}} beats {{x}} when you reuse the template weeks later. Keep static instructions outside the braces and only template the parts that genuinely change, which keeps the form short and the prompt stable. This pairs well with a system-prompt builder: template the system message once, then swap variables per task. Everything runs locally, so confidential templates and values never leave your browser.