Power Prompt Partial

If you've ever copy-pasted the same character description into a dozen workflows, Power Prompt Partial is the fix that doesn't require you to change anything else about how you work. It's a mini version of the main Power Prompt node: same YAML, same variables and fragments, but no prompt: template of its own. Instead it hands its definition out as a component that a main Power Prompt node can pull in over a wire.

Think of it as the prompt equivalent of an rgthree Context node carrying a bundle of connections down one cable: you build the reusable bit once, wire it in, and the main node does the composition. Character sheets, location blocks, style libraries - anything you'd otherwise retype or paste into every new graph.

How it works

A partial's YAML contributes variables: and fragments: to the composition. The variables resolve exactly like they would in the main node - weighted picks, when/unless conditions, tags - except the values flow into the main node's template instead of a template of their own. A prompt: key in a partial is meaningless and ignored, so don't bother writing one.

The node has one input (yaml_input, the partial definition) and one output: a partial socket of the custom POWER_PROMPT_PARTIAL type. Connect that into a main Power Prompt node and its include_1, include_2, … slots appear automatically as you wire more partials in.

Merge order is the thing to remember, because it decides who wins name collisions:

included files  →  wired partials (include_1 … include_N)  →  main YAML

Rightmost wins. So a variable named in the main YAML always overrides one from a partial, and a later include slot overrides an earlier one. There's one subtlety that trips people: variables from wired partials resolve before variables from imported files, so if you need one partial's when/unless conditions to gate options in another, supply the gating variable via a wired partial - an imported file's variables won't be in context yet.

When to reach for it

Use it when you have a chunk of prompt logic that belongs together - say, a character with a hair-color dropdown and an appearance fragment, the default YAML's example. A partial keeps that chunk editable in one place while the main node stays readable. It pairs naturally with the pack's other nodes: a Power Prompt File Partial for file-based libraries, or a plain Power Prompt as the top of the composition.

Installing it

Same pack, same install. Search "Power Prompt" in ComfyUI Manager, or:

cd ComfyUI/custom_nodes
git clone https://github.com/Kramins/comfyui-power-prompt
cd comfyui-power-prompt
pip install -r requirements.txt

Restart ComfyUI and it lands under the prompt category. No models, no extra dependencies beyond the pack's own (pyyaml, jinja2, pydantic) - the whole thing is YAML parsing and a bit of frontend.

Where people get burned

• Putting a prompt: key in the partial. It's ignored. Your fragment renders, your template doesn't, and you'll stare at the main node wondering where the text went.
• Name collisions. Two partials defining the same variable isn't an error - it's a silent override. The later include wins, so don't rely on "the first one" unless you've checked the merge order.
• Cross-partial conditionals. The ordering subtlety above isn't a bug, it's a rule: gating variables belong in wired partials. If an option in an included file never appears no matter what you pick, that's almost certainly why.

If your workflow is one big prompt, Power Prompt Partial is overkill - the main node alone is plenty. The moment you have two workflows sharing a character or a style block, this is the node that stops the copy-paste bleeding.