Skip to main content
Jinja2 lets you keep large, dynamic prompts out of Python strings. The Launchpad ships a small PromptManager service (app/launchpad/services/prompt_loader.py) that loads .j2 templates, parses their YAML frontmatter, and renders them with runtime variables using StrictUndefined so missing variables fail loudly.

Why templates

  • Readable structure — sections like “Role”, “Context”, “Examples” stay visible in the template instead of buried in string concatenation.
  • Reuse — Jinja includes, blocks, and macros let you share common snippets across prompts.
  • Conditional content — show a section only when relevant data is available, or swap tone per user tier.
  • Variable injection — interpolate runtime data without manual string formatting.
  • Frontmatter metadata — each template can declare its own description, author, and any custom fields via YAML frontmatter at the top of the file.

Template locations

PromptManager supports two layouts — use whichever fits the workflow: The quickstart workflow uses the colocated layout — see app/launchpad/workflows/examples/quickstart/prompts/ticket_analysis.j2.

Example template

app/launchpad/workflows/examples/quickstart/prompts/ticket_analysis.j2:
The lines between --- markers are YAML frontmatter. They are stripped before the template is rendered and are available via PromptManager.get_template_info.

Using a template from a node

Drop prompts_dir=PROMPTS_DIR for shared templates in app/launchpad/prompts/.

Inspecting metadata and variables

PromptManager.get_template_info(name) returns the template’s metadata plus the set of variables referenced in the body — useful when wiring templates into a registry or generating documentation:
StrictUndefined is enabled. Any variable referenced in the template but not passed to get_prompt raises UndefinedError — prefer Jinja default(...) filters for optional fields.

Further reading