JinjaRender

Tucked into the pack's tools category - outside the "core nodes" the README actually documents - JinjaRender does one specific thing: it runs your text through Jinja2, the Python templating engine you might already know from Flask apps or Ansible playbooks, and hands back the rendered result as a plain string.

Why this is a different tool from Prompt Control's own syntax

Don't confuse this with the pack's scheduling syntax. [cat:dog:0.3], BREAK, and LoRA tags operate on time - how your prompt changes across the denoising steps of one generation. Jinja templating operates on the text itself, before any of that scheduling syntax gets parsed: variables, loops, conditionals, filters, the works, using Jinja's {{ }} and {% %} tags. If you want to programmatically build up a prompt - loop over a list of tags, conditionally include a clause, substitute a variable from elsewhere in your graph - that's a Jinja job, and JinjaRender is where you'd do it, typically feeding its output into PromptToSchedule or PCTextEncode afterward.

It's genuinely an escape hatch for people who already know Jinja, not something you need to learn to use the rest of the pack. Most Prompt Control workflows never touch it.

The input and output

• text (required, multiline, default empty) - your Jinja template.

Output: a single STRING - the rendered result.

That's the entire schema. No separate variable-passing inputs are exposed on the node itself, so whatever context your template needs has to come from string manipulation elsewhere in your graph (concatenating in values with a node like StringConcat, for instance) rather than a dedicated "pass variables here" slot.

How to install it

• ComfyUI Manager - search "ComfyUI Prompt Control", install, restart.
• Manual - cd ComfyUI/custom_nodes && git clone https://github.com/asagi4/comfyui-prompt-control, restart ComfyUI.

Requires ComfyUI v0.8.0+.

Common issues & troubleshooting

You get a Jinja error, not a Prompt Control error. That's a useful signal, not a bug - a bad template hits Jinja's own parser before Prompt Control's scheduling syntax ever sees the text, so the traceback you get is Jinja's (a TemplateSyntaxError and similar), not a Prompt Control message. Read it as a templating problem first.

You expected variable inputs on the node and there aren't any. Correct, there genuinely aren't - the schema is just the one text field. If your template needs dynamic values, build the full template string upstream (string nodes, another pack's variable nodes) before it reaches JinjaRender.

You don't actually need this. If you're just trying to swap one word for another based on a condition, plain Prompt Control scheduling syntax or a simple string-substitute node from another pack is very likely simpler than reaching for a full templating engine. Save Jinja for when you genuinely need loops or real conditionals.