Context Engineering and Prompt Management
Prompt Templates — Stack
Prompt templates › Stack
Technology landscape as of 2026-10-10. Knowledge cutoff May 2026.
Selection criteria
The choice is mostly a choice about how much power to hand to a text file, and how visible the rendered result is before it reaches a model.
- Expressive ceiling. Whether the language allows conditionals, loops, filters, and arbitrary expressions. More power means fewer templates and less reviewable text.
- Failure on missing input. Whether an undefined name raises at render time, renders as empty, or renders as the literal name. This is the single most consequential default in any template engine for this use.
- Whitespace fidelity. Whether the engine preserves line structure exactly, and whether that behaviour is pinned by configuration rather than inherited from a version.
- Escaping model. Whether values can be marked as untrusted and transformed on substitution, and whether that is the default rather than an opt-in.
- Composition. Support for includes, partials, and inheritance, and whether the composed output can be printed for review without running the application.
- Multi-message shape. Whether the artefact can express a sequence of distinct messages with roles, or only a flat string that something else must then split.
- Round-tripping. Whether the exact rendered text can be captured and replayed, which decides whether a past request can be reproduced.
- Toolchain. Editor support, syntax checking in CI, and whether a reviewer sees a sensible diff when a paragraph is rewrapped.
Options
| Option | Best for | Watch out for |
|---|---|---|
Language-native interpolation (Python f-strings and str.format, JavaScript template literals) |
Short prompts with two or three values and no variation | No escaping, no missing-value protection, and the prompt text is trapped inside source code where non-engineers cannot see it |
Full template engines (Jinja2, Go text/template, Liquid, Nunjucks) |
Large prompt families with shared fragments and real conditional structure | Turing-complete enough to hide logic; autoescape is designed for HTML and is the wrong transformation for prompt text |
| Logic-less engines (Mustache, Handlebars in strict mode) | Keeping branching out of the text by construction | Every branch moves into the calling code, which usually means more code paths, not fewer |
| Typed prompt builders (Pydantic models, dataclasses, or TypeScript objects rendered by a function) | Teams that want the hole set to be a checked interface rather than a convention | The text ends up in code again; reviewability depends entirely on how the renderer is written |
Framework prompt objects (LangChain ChatPromptTemplate, LlamaIndex prompt templates, Semantic Kernel prompt functions) |
Products already inside that framework, where message roles and partials come for free | Framework-specific serialisation makes the template hard to read outside the framework, and defaults change between releases |
Prompt-specific file formats (Dotprompt, .prompty files, POML) |
Keeping prompt, input schema, and model settings in one reviewable file | Small ecosystems; tooling and editor support vary, and portability between runtimes is limited |
| Schema-first prompt DSLs (BAML) | Products where the output contract and the prompt are inseparable and both should be generated | A new language in the build; the generated prompt is what the model sees and is a step removed from what the author wrote |
| Localisation message formats (ICU MessageFormat, Fluent) | Prompts that must exist in several languages with correct plural and gender handling | Built for user-facing copy, not for model instructions; the translation pipeline rarely knows that a changed word is a behavioural change |