What is Prompt Template?
Also called prompt pattern.
A prompt template is a reusable prompt structure with placeholders that are filled with variable data at request time. It separates the fixed instructions, formatting rules, and examples from the changing input, so the same tested prompt serves many cases. Templates are the standard way prompts are managed in production systems.
A template typically holds role instructions, output format requirements, any worked examples, and slots for the variable content. At call time the slots are filled from application data and the rendered string is sent to the model. This mirrors how HTML templating separates page structure from record data, and brings the same maintainability benefits.
Versioning is the main operational reason to use templates. When a prompt lives in a versioned file rather than being assembled inline across a codebase, a behavior change can be traced to a specific revision, compared against evaluation results, and rolled back. Teams typically evaluate template revisions against a fixed case set before promoting them.
Variable interpolation creates an injection surface. User-supplied text placed into a template can contain instructions that the model may follow, since the model sees one undifferentiated sequence. Mitigations include clear delimiters around untrusted content, explicit instructions to treat that region as data, placing untrusted input after the instructions, and validating output rather than trusting it.
Templates also need to respect the model's own conversation format. Chat-tuned models expect messages tagged by role, and hand-assembling those tags into a single string can conflict with the format applied by the interface. Building templates at the message level rather than the raw string level avoids that class of subtle formatting bug.
Key points
- Separates fixed instructions from variable input data
- Enables versioning, evaluation, and rollback of prompts
- Interpolated user content is a prompt injection surface
- Delimit untrusted input and treat it as data
- Build at the message level, not by hand-assembling role tags
In practice
A support tool uses one template holding the tone guidance, a required three-part reply structure, and two worked examples, with slots for the customer message and the account tier. Every ticket renders the same tested structure with different data. When a revision adds a rule about not promising delivery dates, it lands as a new template version, runs against a fifty-case evaluation set, and ships only after the results hold.