Split Prompt

Most ComfyUI users write one positive prompt and one negative prompt in separate boxes. But there's a style of authoring - common in Japanese booru-prompt culture, and genuinely convenient for iterating - where you keep everything in a single line and mark negatives inline with -(tag). Split Prompt understands that dialect: it takes your one prompt, pulls every -(...) out as a negative, and hands you two clean strings to feed your two CLIP encoders.

The README's example is the whole contract:

1girl, smile, -(lowres), -(bad anatomy:1.2), standing

becomes positive 1girl, smile, standing and negative (lowres), (bad anatomy:1.2).

How it works

The mechanism is a single regex pass that matches -(...) tags (including the comma and whitespace in front of them) and swaps them into a negative list, then joins the remaining text as the positive. A few details are worth knowing because they're the difference between "it just works" and "why did my run error":

• Weights survive. -(bad anatomy:1.2) becomes (bad anatomy:1.2) in the negative - the colon-weight syntax is preserved, so emphasis transfers over.
• Colons are validated. The regex enforces at most one colon inside a tag (that's the weight separator). More than one, or a nested parenthesis inside a -(...), and the node raises a ValueError and the run fails rather than silently producing garbage. The author's validation is deliberate: fail loud, don't ship a mangled prompt to the encoder.
• It normalizes :- to :, a small tolerance for a typo people actually make.

Inputs and outputs

Input: just prompt (a string, forced as an input - wire it from a text node or from this pack's Normalize Prompt). Outputs: positive and negative, both strings.

The natural chain is Normalize Prompt → Split Prompt → two CLIP Text Encode nodes. And a note from the prompt-engineering side: negative prompting only does anything at CFG > 1 on most architectures - at CFG 1 the sampler skips the unconditional pass entirely. So if you're running a distilled/Turbo model, inline negatives split here are harmless but mostly pointless; write those as positive constraints instead.

Install

ComfyUI Manager (search "ComfyUI-GadgetNodes"), or:

cd ComfyUI/custom_nodes
git clone https://github.com/2daadv/ComfyUI-GadgetNodes.git
pip install -r ComfyUI-GadgetNodes/requirements.txt

Restart; it's under Gadget/prompt. It's pure Python with no UI dependencies, so it's safe on the Nodes 2.0 frontend - one of the few nodes the README calls out as fine there.

Where people get burned

• The strict syntax is a feature until it bites. A -(tag with (nested)) or a tag with two colons kills the run with a ValueError. That's rare in practice - booru tags don't contain parens - but if a workflow that used to work starts erroring after you add this node, check your tags for stray parens.
• It expects your negatives to be inline already. Prompts written with a separate negative box don't benefit - feed it the positive only and you'll get an empty negative out, which is correct but easy to misread as a bug.

Honest verdict: it's a syntax bridge between two prompt-authoring cultures. If you write -(...) prompts, it's the node that lets you keep doing that and still feed two encoders. If you don't, you've got nothing to gain - but it's well-made for what it does.