Prompt Templates

What it is

A reusable piece of prompt text with named holes in it, plus the rendering step that fills those holes with values and produces the exact string sent to a model. A template is a source artefact: it is authored, reviewed, tested, and localised like any other text resource, and its output is deterministic given the same inputs. The holes are the interface — what the caller must supply and what the template promises to do with it.

Why it matters

Without a template the same wording exists in as many copies as there are call sites, and each copy drifts independently. With one, a wording change happens once and the rendering step becomes the single place where values from the outside world enter prompt text — which makes it the single place to escape them, to assert that nothing required is missing, and to notice that a value arrived empty. The rendered string is also the only artefact that can be compared between a working request and a broken one, so templates are what make prompt bugs reproducible.

Key decisions

• How much logic the template language may express. Conditionals and loops inside the text let one template serve many shapes; they also mean the thing under review is a program whose branches nobody enumerated, and prompt text is reviewed by people who do not read code.
• What a missing or empty value does. Failing loudly turns a data bug into a visible error; substituting nothing produces a grammatical sentence with a hole in its meaning, which the model will answer anyway.
• Whether substituted values are escaped or neutralised at the boundary, since a value arriving from a user or a document can contain text that reads as part of the template's own instructions.
• Whether whitespace and line structure are treated as significant. Models are measurably sensitive to formatting, so an engine that trims blank lines differently after an upgrade has changed the prompt without changing the file.
• How variation is handled: one template with branches, several templates sharing included fragments, or separate templates per case. Each choice decides where duplication accumulates and which changes require touching several files.
• Whether a template ships with the fixtures that render it. A template with no recorded example inputs cannot be reviewed, because nobody can see what it produces.

Failure modes

• Branching accumulates inside the text until the template has a dozen paths, only three of which are ever exercised, and the rendered output for the rest has never been seen by anyone.
• An optional variable renders empty and leaves a sentence like a trailing colon followed by nothing; the model infers a meaning for the silence and answers confidently about it.
• A user-supplied value contains the template engine's own delimiter sequence, and rendering either fails on an unrelated request or splices attacker-chosen structure into the prompt.
• A template is rendered with values whose string conversion is locale-dependent, so a decimal separator or a date format changes between regions and the model reads a different number from the one the application meant.
• A template engine upgrade changes default whitespace handling. Nothing in the repository changed, output quality moves, and the investigation looks at the model first.
• A shared fragment is edited to fix one caller and silently changes the fifteen templates that include it, none of which had tests.
• Templates are forked per tenant to accommodate one sentence of difference, and the next product-wide wording change has to be applied forty times.

Why it is not assembly

A template is an artefact with holes; filling the holes is a pure, local, deterministic transformation of text. Producing the context that is actually sent involves gathering material from retrieval, memory, tool results, and history — sources with their own latency, their own failure behaviour, and their own trust level — and deciding what fits. A template knows nothing about where its values came from or what else is in the request; that is the assembler's problem, and conflating the two is how timeouts and ranking logic end up inside text files.

Related capabilities

• Dynamic Prompt Assembly — the runtime step that renders templates and joins the results
• Prompt Registry and Versioning — where a template goes once it is more than a file
• System and Developer Instructions — the standing text most often held as a template
• Prompt Injection Defense — why the substitution boundary is a security boundary
• Structured Output Contracts — the schema a template usually has to render alongside its instructions

Applies: Production readiness · Design questions